> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
