From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 12:23:35
--- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> > (C) is the biggest issue. The thread_ref you refer to below
> > in this regard. Cancellation requests should really cause instant
> > cancellation during such blocking operations. However, doing
> > a portable manner, especially one that doesn't add overhead to
> > operations, is very difficult to do.
> The only way to do this (UNIX) is by sending the thread a signal.
Not true. All that would be required is to have the Boost
synchronization primitives built on top of a complex condition
variable that can watch both the state it's interested in (such as a
mutex being unlocked) and for a cancellation request. Trivial to
implement, but it means severe overhead on all synchronization
I'm sure there are other solutions as well, but none are both
efficient and easily portable.
There's likely no solution for C, and Boost.Threads may well have to
ignore this issue. But I'm not ready to give up with out a fight ;).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk