[boost] Re: Asynchronicity (long)

From: Boris (boris_at_[hidden])
Date: 2005-03-29 08:24:43

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

> [...]