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