Boost logo

Boost :

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2002-11-25 17:37:34


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk