Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-14 14:32:10

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > Why make users reinvent the cancellation wheel?
> >
> > They shouldn't have to. Boost.Threads will include cancellation
> > some point. I just want to insure we do it correctly.
> OK, no problem with that; but the fact that boost.threads doesn't
> cancellation (how many Ls go into that word?) is a severe
> 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.

I can take the easy way out and ignore (B) and (C), as you did for
thread_ref, but I'd rather try and flesh this out correctly. After
all, this form of cooperative cancellation is extremely simple to do
in user code with out direct support from the library simply by using
a condition.

> that has been refined in the associated thread (ignore the
> part.)
> Alexander Terekhov pointed out that some vendors already implement
such a
> mechanism:
> I've tried to sketch a 'proof of concept' implementation at
> My opinion is that we should simply ignore the 'catch(...)' issue,
and not
> support asynchronous cancellation, at least for now. Give the users
> something that works.
> > In the mean time, cancellation can be simulated trivially in user
> > code, and that work around is what Beman wants documented.
> My point was that if simulating cancellation is so trivial, we
> include the code that does this in boost.threads, not make users
> it. It will be at least a starting point.

However, if we do it wrong and have to do it differently in the
future we stand a large chance of breaking code that depends on our
implementation. I'd rather avoid that by at least attempting to do
it right from the beginning, *especially* since it's trivial for a
user to do this with out built in support.

Bill Kempf

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