Pipes supports 'select', which allows one to receive on multiple ports at the same time. The new scheduler doesn't have a solution for this, but it needs to be more general than the old one.
Some types of events we might want to wait on:
- Port receives, both one-shot, stream and other receives
- I/O reads of all kinds
- Timers
- Socket accepts
Miscellaneous notes:
The biggest requirement is that we need one abstraction that allows for waiting on both I/O events (single-threaded) and comm events (multithreaded). uv handles and comm types have very different implementations.
select may not be the right abstraction. Maybe there are more expressive ways to do this. We could for instance have an event loop with callbacks. Also look an .NET's async I/O which I know nothing about. Needs more research.
Asynchronous I/O events should hopefully allow for all the various extension methods and decorator types that synchronous I/O allows.
The solution should additionally be workable for tasks that are not coroutines scheduled by an I/O event loop. We would like to have tasks that are backed simply by threads and don't use the I/O event loop and that makes the design of various runtime components more difficult. It's potentially ok not to solve this yet.
Some types of events need to be cancellable as well, e.g. if you wait on both a timer and an accept, if the timer goes off first you may want to cancel the accept.
Pipes supports 'select', which allows one to receive on multiple ports at the same time. The new scheduler doesn't have a solution for this, but it needs to be more general than the old one.
Some types of events we might want to wait on:
Miscellaneous notes:
The biggest requirement is that we need one abstraction that allows for waiting on both I/O events (single-threaded) and comm events (multithreaded). uv handles and comm types have very different implementations.
selectmay not be the right abstraction. Maybe there are more expressive ways to do this. We could for instance have an event loop with callbacks. Also look an .NET's async I/O which I know nothing about. Needs more research.Asynchronous I/O events should hopefully allow for all the various extension methods and decorator types that synchronous I/O allows.
The solution should additionally be workable for tasks that are not coroutines scheduled by an I/O event loop. We would like to have tasks that are backed simply by threads and don't use the I/O event loop and that makes the design of various runtime components more difficult. It's potentially ok not to solve this yet.
Some types of events need to be cancellable as well, e.g. if you wait on both a timer and an accept, if the timer goes off first you may want to cancel the accept.