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