Kernel trap redesign - Inter-Task Comms + Multiple Wait

[tmontes]

Current Status

Existing traps:

Trap	Blocks?	Notes
direct-clear	No	Direct terminal output.
direct-print	No	Direct terminal output.
window-create	No	Create and return a Window.
window-render	No	Update terminal output.
window-destroy	No	Destroy Window and update terminal output.
sleep	Yes	Return after N seconds.
read-key	Yes	Return byte corresponding to terminal input.
put-key	No	Pushback byte to other read-key waiting tasks.
task-spawn	No	Create a child Task.
task-destroy	No	Destroy child Task and all of its children.
task-wait	Yes	Wait for any child Task completion.
dump-state	No	Logs kernel state.

Future library design seems to indicate the need for one or more kernel traps to support inter-task communication. This will lead to, at least, one more trap that blocks the calling task (assuming a simple message-send / message-receive like trap pair).

This type of design, while somewhat intuitive, leads to an unnecessary limitation. Waiting/blocking on multiple things:

• What if one task wants to block, waiting for either a child task termination or 5 seconds?
• What about waiting for either keyboard input or a child task termination or a message from some task?

Possible Solution

• All Tasks will have an INBOX, where they receive messages.

• There will be two new kernel traps to support inter-task communication:

  • message-send: sends a message (any object) to another Task, does not block.
  • message-wait: returns the 1st message in the INBOX, or blocks until there is one.
    • Actually returns a (<sender>, <value>) tuple where <sender> will be the sender Task or None if the message is originated from the kernel.

• Inter-task communication:

  • Only supported between parents and their children.
  • message-send takes two arguments: the destination Task and the message.
    • Parents can easily send messages to their children.
    • Children can send messages to their parents by using None as the destination Task (or some TBD constant).

• About waiting for multiple things simultaneously:

  • Currently blocking traps, like sleep, read-key and task-wait will no longer block: they will return some kind of "request id" the caller must track.
  • The calling task must message-wait to confirm their completion: the kernel will send a message to the task once any of the pending requests is completed. Such message will itself be a (<request-id>, <result>) so that the waiting task knows what completed.

• Simpler, blocking variations of the traps can be implemented at a library level.

Will certainly need adjustments, but I like the idea of "async traps" and a single "blocking trap" a lot.

Broken down this issue into:

• Implement inter task communication with two new traps. #45 - Implement inter task communication.
• Make all (most) traps non-blocking. #46 - Make all traps except message-wait non-blocking.

[tmontes]

Tracked in #46 which also links back here. Closing.