Boris and Hamish have presented examples using objects that
provide fat interfaces for event notification. By this I mean they use
seperate onEvent() handlers for each type of event as member functions
of an event sink or observer class.
ACE (I think) uses enums to register interest in read/write, close, exception
activity on a resource.
What are the features that should be supported? I'll have a go:
* a multiplexing library should cope with:
files,
sockets,
timers,
signals,
user interface events (though need more description for this)
others not mentioned but probably useful - pipes, named pipes
* should be simple. Not as many "design rules" as
http://www.cs.wustl.edu/~schmidt/PDF/reactor-rules.pdf
* should allow the use of function objects as handlers
* one handler per (event, resource) pair
* should allow reuse of handler for different (event,resource) pairs
* should not provide for handler reuse across multiple multiplexers,
as the only use of multiple multiplexers would be in multiple
threads.
* should not require virtual base class interface
* the implementation could use select, poll, epoll WaitForMultipleObjects
or anything else that is available.
* should accept the native descriptor types (socket, file, etc) and
do the "right thing"
I have tried to collect previous comments below:
Hamish MacKenzie
http://aspn.activestate.com/ASPN/Mail/Message/boost/1448661
Boris Schaeling
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/Multiplexing
Thread concerns
Markus Schoepflin
news://news.gmane.org/gmane.comp.lib.boost.devel/12399
Eric Woodruff
news://news.gmane.org/gmane.comp.lib.boost.devel/12337
Hu Xinwei
news://news.gmane.org/gmane.comp.lib.boost.devel/12414
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
