Date: 2001-10-13 00:52:38
--- In boost_at_y..., Carl Daniel <cpdaniel_at_p...> wrote:
> Conservation of worker threads (which translates to a decrease in
working set and a decrease in context switches).
> Since Win32 lets one wait on (at least) 64 objects simultaneously,
it's frequently more efficient to use one (or a few
> threads) to service a large number of events.
WaitForMultipleObjects also lets the caller specify whether to wait
> any of the objects or to wait until all are signaled
simultaneously. The latter behavior is rarely used, but difficult
> to simulate when not available. In the former case, the value
returned from the call indicates which object was
A possible pthread-version of WaitForMultipleObjects
that comes to my mind is that
WaitForMultipleObjects defines a new "compound signal",
then starts a thread for each of the multiple objects,
and then waits for the compound signal.
The individual threads for the multiple objects
just wait for the respective object
and then signal the "compound signal",
which tells WaitForMultipleObjects to return.
This, however, is just theory,
it might consume too many thread ressurces in practice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk