Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-15 08:33:31

From: "bill_kempf" <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > FWIW here's an old proposal of mine:
> >
> >
> Yes, this old thread has been used to solidify my working mental
> design. However, there are issues to work through:
> A) Can the user catch the exception? (Probably the only choice
> available for Boost.Threads.)


> B) Can the user "eat" the exception?


> C) How do you portably and efficiently handle cancellation points?
> (A) is probably the easiest, though the only viable choice is frought
> with problems. If user code has catch(...) blocks it may well cause
> hard to diagnose bugs, and if this code is in a library the user may
> not be able to work around the bugs. I expect this is something
> we'll just have to live with, and practice may prove it to be a non-
> issue, but it still concerns me.
> (B) has pros and cons for both choices and needs some serious thought.
> (C) is the biggest issue. The thread_ref you refer to below failed
> in this regard. Cancellation requests should really cause instant
> cancellation during such blocking operations. However, doing this in
> a portable manner, especially one that doesn't add overhead to such
> operations, is very difficult to do.

No, thread_ref did not fail. An existing implementation that approximates
the "truth" to the extent of being useful is better than a perfect
implementation that does not exist yet.

Peter Dimov
Multi Media Ltd.

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