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

From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-08 20:13:56

On Thu, 8 Jan 2004, Michael Glassford wrote:
>
> Roland wrote:
>
> > Boost.Thread could supply intermediary (platform dependant)
> > functions to enable eventual IO lib designers a uniform interface.
> >
> > i.e. on Windows supply a
> > cond.wait_wfmo(L& lock , DWORD nCount, CONST HANDLE* lpHandles)
> >
> > while on Posix supply a
> > cond.wait_select(L& lock, int n, fd_set* readfds, fd_set* writefds, fd_set* exceptfds)
>
> Wouldn't it be better to wrap the parameters to the above functions into
> a class and combine the functions into one? Something like this:
>
> cond.interruptible_wait(L& lock, const I& interrupt_list)
>
> where interrupt_list is a list of "interrupt objects" that wrap the
> platform-specific stuff? This would at least help localize the
> platform-specific code.

Forgive me for coming into this a bit late.  Is the goal here to build
hooks into the thread library to make it useful for network programming or
to develop the framework for a network library that builds off of the
thread library?  If it's the former, I'm not sure anything need be done.
Threads can already be created and whatnot.  If it's the latter... that's
a fairly complicated issue.  I'm going to assume the latter and play the
role of network programmer.

Assuming you want to allow the network programmers to use any available IO
method, there are significant structural differences to be dealt with.
Some use a select-like structure and others use kernel-level signalling.
And state information has to be communicated in each case as well.  It
might be enough to assume a thread pool-like model where worker objects
register themselves and wait on a blocking call.  When they're woken up
they would be passed an object containing relevant state information and
an object containing the data.  The state info will also obviously be
method (and platform) dependent.

>From there I assume the network programmer has two choices, he could
either associate, say, a socket handle with a generic identifier and pass
on the data as-is to a platform-neutral layer for parsing or he could
cache data until a complete message was assembled and pass this on
instead.  Assuming the second model, provisions would have to be made for
multiple layers of data interpolation (encryption, compression, etc) in
order to recognize the end of a message.

Sean