On Wed, 2002-11-27 at 20:40, Johan Nilsson wrote: > Just adding some comments here. > > Being able to queue _true_ async read/writes on multiple devices (socket, > files, serial devices, pipes, ...), and then wait for any of them to > complete has been absolutely essential to me - much, much more than > non-blocking (which I personally don't like at all), and also more than > multiplexing (select). That's probably why I'm not doing linux programming > if I can avoid it (no flames please). I started out to implement > cross-platform async I/O for NT/linux/VMS, and got a bit on the way before > having to drop the multiplatform support (at least currently) due to > resource limitations (time, mostly). Anyway, one can always fake async i/o > on linux using i/o multiplexing. I also made some attempts on using libaio, > but it didn't seem very mature at the time - maybe one will have to wait for > kernel aio support. Under VMS as well as under NT, the i/o subsystems are > designed as asynchronous, so there are less work there (even though VMS I/O > is not as 'polymorhic' as NT's). > > Regards // Johan
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? -- Hamish Mackenzie <[EMAIL PROTECTED]> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
