Re: [boost] Re: Re: Boost.Thread : IO multiplexing

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-27 20:51:25

It seems that network sockets are the most common use case for
nonblocking I/O multiplexing (i.e. the reactor pattern).  If a library
restricts itself to those alone, an efficient portable implementation
may be possible.

Note, for example, that AFAIK, polling multiple file descriptors for
reading or writing (this is not the same as waiting for asynchronous
completion) is not possible under the Windows API, while under POSIX,
Linux, and BSD, AFAIK, it is not possible to wait on a set of mutexes or
condition variables while also polling a set of file descriptors.  These
two constraints effectively rule out creating a boost i/o library that
can handle polling anything but sockets.  Clearly, using multiple
threads to attempt to emulate this type of polling is not a viable
solution, because it would likely be highly inefficient.

On the other hand, I believe it would be possible to create a portable
library which utilized either WSAAsyncSelect or select on Windows
platforms, kqueue on BSD platforms, epoll on Linux kernels that support
it, and poll on other POSIX platforms.  (On Solaris, I believe it would
be possible to utilize /dev/poll.)

As far as asynchronous read/write (on sockets) handling, I do not
believe it is possible to unify waiting for asynchronous completion with
the type of polling described above, at least on POSIX platforms.  It
would be possible to create a portable library for waiting (only) for
asynchronous completion of a read or write.  One issue with the POSIX
asynchronous i/o interface is that it does not, AFAIK, support reading
or writing asynchronous out-of-band data on TCP sockets.  I suppose
though that since out-of-band data is not used all that often, this is
less of an issue; still, it is a reason for people to use polling
rather than asynchronous read/write, particularly since in a network
server, it would be necessary to have at least one thread waiting to
accept new clients.

-- 
Jeremy Maitin-Shepard