Re: first sight

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 
at
> > some point.  I just want to insure we do it correctly.
> 
> OK, no problem with that; but the fact that boost.threads doesn't 
have
> cancellation (how many Ls go into that word?) is a severe 
limitation.
> 
> FWIW here's an old proposal of mine:
> 
> http://groups.yahoo.com/group/boost/message/16471

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 
suspend/resume
> part.)
> 
> Alexander Terekhov pointed out that some vendors already implement 
such a
> mechanism:
> 
> 
http://tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51_PDF/ARH9RB
TE.PDF
> 
> I've tried to sketch a 'proof of concept' implementation at
> 
> http://groups.yahoo.com/group/boost/files/thread_ref/
> 
> 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 
should
> include the code that does this in boost.threads, not make users 
reinvent
> 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