Don G wrote:
Hi All,
I've renamed the subject from "Asynchronous I/O" because I wanted to float the notion that async behavior not be viewed as an aspect of I/O, though it is highly desired in that space.
Hi Don, sorry for my late answer but work caught me again. At least it's good to see others jumping in and keeping the discussion alive. :)
[...] ------ Sketch --------
1. The user creates one or more "nexus" objects. These objects store the queue of events, typically one-per-thread. Since some action is typically required as messages are enqueued, a callback is supplied to open() which gets called as each message is added.
It reminds me of I/O completion ports - several ports each of them handling several events? Is your idea similar to this?
2. The owner of the nexus is responsible for calling the pump() method to drain the messages. This method is intended for only one thread and hence is not internally thread-safe (i.e., BYOM ... Bring Your Own Mutex).
3. To queue calls, client code needs to create a "channel" object and connect it with a nexus. The reason for this object is that it is a proxy for the "ability to still dispatch a message". In other words, if a receiver object finds itself in its destructor, it will want to cancel any queued calls to it. Of course, this can be applied externally to objects, which is why channel is not a base class.
4. Once a channel is open, the async_call() method is used to put a message in flight. This is thread-safe.
5. Where other code needs a function<>, the channel can be used to create a shim function<> that accepts N arguments, and binds them into a queued call.
------ Pseudo-code --------
class nexus
The concept of the class really reminds me of a I/O completion port. The only difference is that there is no invisible background thread being responsible for a nexus object - the application has to make sure that there is one thread controlling a nexus object?
[...] class channel
AFAICS you use this class to communicate with a nexus object. The owner thread does the multiplexing (waiting for different events in a nexus object) and other threads communicate with this nexus object through channels which are responsible for synchronizing? Is this correct? So the difference between your approach and I/O completion ports in Windows is ... hm, I think in Windows a completion port is a combination of your nexus and channel, isn't it? Boris
[...]