[boost] Re: Re: Socket Multiplexing

From: Michel André (michel.andre_at_[hidden])
Date: 2002-11-28 12:09:50

> I have not used async io, so I am a little out of my depth here.  If we
> were to create an interface that could be implemented using select or
> aio what design constraints would that impose?
>
> I am guessing the callbacks would be free threaded.  Is that right?

The interaction model with async IO is completeley different from using
select or WSAEventSelect based mechanisms. When using traditional select
based youre getting notified when there is something to read or when you are
able to write without blocking. Referring to POSA2 by Scmidth et all this is
Reactive and therefore the name of the Reactor pattern. On the other hand
async io you post reads and writes that may complete or may not complete
together with some token or context (asynchrounous completion token) to the
client state and the buffer to read or write from ie proactive (post a read
in case somebody writes to you) and queue a write and get notification when
its done regardless if the stack is ready to receive it.  Referring to POSA2
by Scmidth et all this is proactive and therefore the name of the Proactor
pattern for event multiplexing. The two strategies uses different sets of
multiplexers
and connection/acceptors/connectors than the more traditional interface.
Therefore I think that an async io package will be a new addition to the
socket library or a completely new library. I don't even now if its possible
to implement async aio in a consistent manor on all platforms (or at least
sufficient number) that is of interest to boost, but it could be simulated
via another multiplex mechanism and threads I guess.

And yes the callbacks should be free threaded, since if several threads is
picking completions of the completion queue notifications will come on any
of those threads.

Regards
/Michel