Issues with kern.sire and cog/driver architecture

[kjekac]

Wastebasket issue to keep track of things as we discover them. Might be broken into separate issues in the future or just inform the design of the next kernel.

• Drivers don't compose -- the cog needs to manually wire them up with handlers and whatever instead of connecting them into a big "my outside"
• Can't do join semantics -- since drivers have write handlers, we can always only handle one incoming message at a time.
• listen and send (driver, 0) are a very ugly hack.
• send is susceptible to race conditions -- whenever the cog does a send, it takes the existing sl value and applies it to the message. If the driver hadn't yet handled that value, this will likely crash, or worse it could introduce weird unintended behavior.
• The write handler architecture makes the whole thing very prone to spaghetti code.
• Cog can't initiate actions (probably good but need to build something that makes it ergonomic to do something like that -- might simply be solved by starting a driver that looks for your private keyfile as the first action).
• Drivers can't message each other. (Might not be required if the cog is sufficiently good at generating composed drivers?)
• Drivers can't ask for (cached) eval jobs (would be helpful for building the database in layers of caches without hitting the event log)
• Drivers and cogs both have multiple entry points. For cogs this works since it has separate state management, but for drivers this means that we can't e.g. do connection reuse (can't look up the ip and port in a map to find out if there's an open socket).
• ignore frees up slots too eagerly, which means that this:

  = (ddd return)
  : _ < launch_ %foo
  : _ < launch %bar
  | return ()
  

  Gives us this: | DRIVER_KERNEL 0 [0 0-((a b & a-0) DRIVER_DONE)] [[1 %foo] [1 %bar]] Which means that ignore and launch_ are unsafe to use on anything other than DB_WRITE.
• ...And launch is more or less unsafe to use on DB_WRITE... this whole duality is pretty weird, but we knew that. It should pretty obviously not be exposed to the user in this way.