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
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.
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk