[boost] Re: Asynchronicity (long)

From: Don G (dongryphon_at_[hidden])
Date: 2005-03-29 10:37:34

Hi Boris,

No problem on the delay. I sometimes have long spells of silence due
to work/family/church/life-in-general. :)

My answers / opinions are below...

--- Boris <boris_at_[hidden]> wrote:
> 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 --------
> > [...]
> 
> It reminds me of I/O completion ports - several ports each
> of them handling several events? Is your idea similar to this?

It is similar, but the channel concept has no analogy. Then again,
most async mechanisms are similar, it's just in the details that they
diverge<g>. QueueUserAPC + SleepEx(ALERTABLE) is also similar, but
again lacking the channel notion. The closest analogy in Windows is
the USER thread message queue, an HWND and Get/DispatchMessage +
PostMessage. I believe one can find nearly a one-to-one
correspondence with that model.

> > ------ 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?

Essentially, yes. Nothing is hidden with the possible exception of
how does some body of code know the proper nexus object to which a
channel should be connected. This can be explicit, but a
thread-specific data item is also compelling.

> > [...]
> > 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?

If I understand you correctly, Yes. The channel objects are the means
by which the user enqueues events to a nexus object and a different
piece of user code calls the nexus object to dispatch/dequeue the
messages.

> 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?

It is basically that, yes. The channel class, however, I believe to
be a very important concept. Merging it with the nexus class would
create dangerous situations where one would have to ask at the point
a message is enqueued: "will it be OK to deliver this message
regardless of what might happen between now and the time of
delivery?" The key impulse that can make this answer always NO is
"delete foo". The delete operation is synchronous. Without a channel
to serve as a way to cancel pending messages to that object, we would
have dangling pointers in the queue (a bad thing).

Best,
Don

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/