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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-23 21:05:14

On Fri, 23 Jan 2004, Michael Glassford wrote:
>
> Sean Kelly wrote:
> >
> > I'm not sure that much if anything would need to be done to provide
> > support for IO multiplexing in Boost.  Both methods rely on the
> > existence of a thread pool.  Each thread waits on a blocking call
> and
> > then operates on the data returned.  This can all be done right now
> > without any modifications to the Boost code.
>
> That, of course, would be the best solution. Have you looked at the
> code in the orignal post to see if such a solution would solve his
> problem?

I just tracked it down on the newsgroup (Boost.Thread: Wrapping Native
Windows Event Variables	possible?).  I think Roland's problem is more one
of overall program design than any failing of the Boost code.  The idea
that there could be thread contention for tcp_port::write concerns me.  A
socket operation may only write a portion of the buffer on a given call,
while granularity at this low level seems to assume that the entire buffer
will be written.  I would be surprised if this did not result in out of
order data on the reciever side no matter how the rest of this program is
designed.

Regarding the later question: "How do I simultaneously wait for a
condition _or_ a pending IO operation becoming notified/signalled."  The
simple case would be to rely on any signalling mechanism built into the IO
structure.  IOCP has PostQueuedCompletionStatus, and I'm not sure if
there's something equivalent for /dev/poll.  However I do think it would
be possible to use boost::condition for this, which I assume is what
Roland meant by providing hooks for IO operations.  I'll have to think
about it a bit more, but I'm not sure that any additional Boost methods
would need to be provided.  It would be a matter of whether an IO thread
within a thread pool signalled because data was ready or because another
thread signalled for some other purpose.

I haven't decided whether using conditions for IO in this way is an
efficient use of resources however.  It seems to require more threads
than are necessary just to fit into thhe condition/wait design pattern.
But I'll give it some more thought tonight.  Perhaps I'll try to build
around this concept when I get a chance to work on my IO lib.

Sean