From: Sean Kelly (sean_at_[hidden])
Date: 2004-01-08 22:57:56
On Thu, 8 Jan 2004, Hurd, Matthew wrote:
> The first idiom, of timed waiting and predicate checking, or something
> else would still be required for active object cancellation where the
> object is waiting on OS blocking things and you don't have a WFMO
> equivalent though.
> Without a WFMO equivalent a boost implementation would have to:
> 1. block on each of them with a separate thread
> 2. be able to stop the other waiting threads from waiting when one
> It is not pretty.
> So I think boost needs a portable interface to a WFMO equivalent. Is
> there an equivalent for POXIS, linux, solaris that is appropriate.
> Perhaps a WFMO abstraction would be appropriate for asynch I/O?
Depends on the type of IO. The only way to interrupt select() is to send
data to a listening socket it's polling or close a socket it's polling.
IIRC there is a way to signal IOCP to wake up though, I do it in the
destructor of some of my comm. objects.
> A general implementation without direct OS support could have built with
> timed blocking (very ugly) or cancelling threads (still very ugly just
> less so from a performance viewpoint but perhaps more so from a
> robustness viewpoint). I don't think either of these are appropriate
One slightly irritating feature of pthreads is that there's no supplied
way to determine whether a thread has exited. A suggested method to
shutdown a thread might be to signal it and then join it, but IMO you
would still want to have the wait for completion to time out as I can
think of a few instances where waiting indefinately for completion
could cause problems.
> Solving the cancellation with allow the messy solution of having various
> threads blocked waiting for individual objects to work, but it is still
> ugly and wasteful and should cause you to run a few miles in the
> opposite direction.
If the thread loop is written correctly a timed wait isn't much of a
performance hit, and in some cases the only workarounds are complex and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk