Make all (most) traps non-blocking. about ppytty HOT 2 OPEN

Idea for message matching:

• Messages in a tasks INBOX will be (sender-task, key, message) tuples.
• message-send will take two or three arguments:
  • destination-task and message as it does now.
  • destination-task, message and key.
  • key will be assumed to be None if omitted.
• message-wait always returns sender-task, key and message.
  • sender-task will be None for messages sent by the kernel, with:
    • key will be the request-id returned by the async trap call.
    • message will be the async trap result.
  • sender-task will otherwise be the task that called message-send.
• message-wait will take zero, one or two arguments:
  • Zero arguments: returns the first message in the INBOX if any, otherwise blocks.
  • sender: returns the first message in the INBOX from the given sender, otherwise blocks.
  • sender and key: returns the first message in the INBOX from the given sender with the given key, otherwise blocks.

This provides good support for async traps as in:

def task():
     request_id = yield ('sleep', 5)
    _sender, _key, _discard = yield ('message-wait', None, request_id)
    # _sender is guaranteed to be None, per the sender passed to message-wait: meaning the kernel
    # _key is guaranteed to be request id, per the key passed to message-wait: meaning the sleep trap
    # _discard is whatever the sleep trap returns which is actually None.

...which, given none of the returning values are actually useful, could be written as:

def task():
    request_id = yield ('sleep', 5)
    yield ('message-wait', None, request_id)

from ppytty.

This issue stems from the potential need to wait/block on multiple things:

• Timers.
• Keyboard reads.
• Child task termination.
• etc...

With the current task-wait and message-wait traps that is already possible, even though it needs to be done at a higher level: current solution depend on a task spawning a child task for each of the "things" it wants to wait/block on. Then either task-wait or message-wait will handle any of the child tasks results or messages.

Given this, I'll be deferring this interesting but maybe non-fundamental issue into TBD.

from ppytty.