Boost logo

Boost :

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2002-11-27 15:40:14


>"Darryl Green" <Darryl.Green_at_[hidden]> skrev i meddelandet
>news:4FCBBCDBF9232241B8D2031F2DD74DCB0D6CCB_at_[hidden]
...

[snip]

> Note man says "regular files" - there are lots of interesting special
files that don't always
> report ready - I/O devices, pipes etc. Also, I think it would be a bad
idea to assume
> that select is the be all and end all of how the socket/file/whatever
ready to handler
> dispatching can be implemented. It ought to be possible to replace a
select based
> dispatcher with one based on async I/O or some other exotic scheme.

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk