"Michel André" <[EMAIL PROTECTED]> wrote in message 0dde01c29700$f6cd7790$a400a8c0@orbit">news:0dde01c29700$f6cd7790$a400a8c0@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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
