As the discussions around futures are spread in many places, I prefer to post this on this high-visibility forum, where I know core developers like @alexcrichton and @aturon are likely to be around. If there is an existing discussion thread on this matter somewhere, please point me towards it.
It took me a long while to wrap my mind about the general design of futures-rs, but my current perception can be summarized as follows: you start by building a state machine associated with a certain asynchronous task using future/stream combinators, and in the end you pass it down to an event loop, which takes care of “running” the state machine until its final state is reached by polling it repeatedly as the relevant input events arrive (which, in turn, triggers execution of relevant event handling code and state transitions).
On its side, the event loop receives a stream of OS events in an implementation-dependent way (in a Tokio setting, this would be mio, which itself hooks into epoll on Linux), and associates them with futures/streams by leveraging the fact that a certain future/stream has registered interest into a certain OS event.
Now, if my understanding is correct, here is what I am wondering about: as long as host system resources are plentiful, input events can be handled in a FIFO fashion, and it will optimize the overall latency and throughput very well. But as soon as the system is under load, we may need to prioritize some tasks over others in order to fulfill our latency constraints. For example, an audio application which asynchronously receives audio frames from the network and asynchronously feeds them into a sound card driver may want to prioritize delivering audio frames to the driver over receiving them from the network in order to avoid sound card buffer underruns (which result in very ugly glitches in the audio output). This requires reordering “sound card driver wants audio frames” events before “server received audio frames” events, for example by using something like a priority queue for OS-application communication instead of a FIFO queue.
Have this kind of task prioritization issues been considered so far by the futures-rs designers? And if so, how would you plan to handle them?