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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-28 22:30:02

Jeremy Maitin-Shepard wrote:
 >
> As far as I know, it is not possible to poll file descriptors (HANDLEs)
> using the Windows API. . . This can't even be solved
> by using multiple threads --- I believe that polling is simply not
> supported on Windows.  Asynchronous completion of socket read
> operations and file read operations can indeed be unified, but I would
> not suggest that a boost library not implement polling.

IOCP works for both file and socket operations.  Perhaps not a poll 
method but I'm not much interested in the low-end solutions anyway.

> AFAIK, neither /dev/poll nor epoll provide similar functionality to
> completion ports.  /dev/poll, epoll and kqueue poll a file descriptor
> for _available_ data to read, _available_ buffer space to write,
> _available_ out of band data to read, in the case of a connecting
> socket, a socket which has connected, and in the case of a listening
> socket, an _available_ new connection to accept.  Windows completion
> ports, in contrast, allow you to determine when a particular write
> operation or read operation has been completed.  Thus, this is a
> fundamentally different model.

That doesn't mean they can't use the same basic model though.  With IOCP 
when a read operation unblocks the data is already in the buffer while 
with the other methods a read operation has to be done.  Wrap that bit 
in the IO subsystem.  The DDJ article is actually good in this 
respect--it serves as a useful example of how to combine the two 
methods.  Just grab it from their website, it's in the Feb. 2004 issue, 
file is iomulti.zip.  I think it needs a bit of work, but the basic 
approach isn't too bad.

What remains an issue in my mind is how far to take this.  Socket and 
file classes for each platform at least... what else?

Sean

Sean