|
Boost : |
From: Hamish Mackenzie (hamish_at_[hidden])
Date: 2002-11-28 06:04:16
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 <hamish_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk