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

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-01-29 07:01:36

On Wed, 28 Jan 2004 23:04:57 -0500, Hurd, Matthew wrote
> > On Behalf Of Sean Kelly
> > 
> > What remains an issue in my mind is how far to take this.  Socket and
> > file classes for each platform at least... what else?

Sorry to jump into the conversation mid-stream... 

I'm hoping you'll have looked at 

http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket

which documents prior work in this on sockets and multiplexing by a variety of
boosters.  The work seems to have stalled out, but there is an implementation
in the sandbox along with requirements, etc.

> Waitable timers would be the other "main" one I'd guess.

Yep, that's a big one.

> Some process abstractions might be straight forward for "kill" 
> signals and the windows equivalent.
> 
> I would still like to see mutexes, timers, socket i/o and file i/o 
> all with similar acquisition concepts so there is a hope of marrying 
> them down the track if it is not done up front.

In ACE this the the Event_Handler class.  

http://www.dre.vanderbilt.edu/Doxygen/Stable/html/ace/a01234.html

However, in my mind this class doesn't go far enough because it tightly
couples timer callback interfaces (handle_timeout) with file i/o
(handle_input) and signals (handle_signal). Thus a pure timeout handler, for
example, brings a lot of baggage as well as virtual functions.

In the brave new world of policy design it seems like we should have an
EventHandler class that can take a list of reactive handler classes/policies
so that the designer can mix and match to generate a handler class which can
respond to several of these different input types.  Of course the reactor type
needs to be a policy as well because despite the limits of WFMO it might be
the prefered choice on Windows while a Select reactor might be used on Unix --
and the code would still be portable for a large percentage of applications.

> The other thing I'd like to see is a substitutable framework, like 
> the synch stuff I posted a while ago, where you can develop to a particular
> policy concept, for example a shareable mutex, then substitute a single
> threaded or null mutex or anything else in.  ACE has had something
> similar for many years and it is straight forward.  The current

Yes, I agree with this is important. It is a case where ACE had policy-based
design b/f it was 'popular'.

> interface does not support such use AFAICT, hence the synch wrapper I
> use.  I'd be happy to document and clean this up if there is interest.

Absolutely.  And more globally I'd like to see a small working group get
organized and actually bring these libraries to the point where they can be
included in boost...

Jeff