Boost logo

Boost :

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-12 06:17:25

> 2. It is unavoidable that this library uses threads.

There are two main reasons that I see:

1) On windows we have a limitation of at most 64 'Event' objects
   that can be 'waited' for at a time. This is not enough
   for large server applications that might need thousands
   of TCP/IP sockets.

2) On windows there are different types of handles/events. It
   seems to make a lot more sense to use different threads
   to wait for different types. For example, there is a
   WSAWaitForMultipleObjects (for sockets) and a WaitForMultipleObjects
   that allows one to wait for arbitrary events (but not socket
   events(?)). More in general however - there seems to be
   a need to use different ways to demultiplex and handle
   different types - even if the handles of all different types
   are the same (ie, 'int' on UNIX). Consider the major
   difference between a listen socket, a very busy UDP socket
   and a very busy memory mapped filedescriptor. It might be
   easier to regular priority issues between the different types
   by putting their dispatchers in separate threads.
   Note however that I DO think that the callback functions
   for each event (that is, the moment we start calling IOstream
   functions) should happen in the same thread again; this
   new library should shield the use of threads for the user
   as much as possible!

Carlo Wood <carlo_at_[hidden]>

Boost list run by bdawes at, gregod at, cpdaniel at, john at