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