|
Boost : |
From: Robin.Hu (huxw_at_[hidden])
Date: 2002-11-28 08:05:10
On Wed, 27 Nov 2002 21:40:14 +0100
"Johan Nilsson" <johan.nilsson_at_[hidden]> wrote:
>
> >"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
The biggest problem is portablity, but it worth a try. ;-)
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- <huxw_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk