Boost logo

Boost :

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2002-11-29 06:09:36

"Michel André" <michel.andre_at_[hidden]> wrote in message
> > 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?

[big snip]

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

OTOH, if we're discussing i/o in general - there are several platforms that
doesn't directly support multiplexing on other devices than sockets, as
NT/VMS (and the actual implementation in these cases are beyond my
knowledge). Implementing async i/o in terms of multiplexing should be easier
than the opposite way around, if the latter is even possible.

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

_If_ callbacks are used. Async i/o and callbacks are not necessarily
associated with each other (but maybe the discussion was just in the context
of callbacks, I came in pretty late). And even if callbacks are used in the
library to emulate async i/o, the user needn't be notified in a
free-threaded fashion (e.g. the aio_xxx implementation under linux).

Just my $0.02.

/ Johan

Boost list run by bdawes at, gregod at, cpdaniel at, john at