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
news:0dde01c29700$f6cd7790$a400a8c0_at_orbit...
> > 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
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.

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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk