Re: [boost] Comments about N2320

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-01 09:51:38

"Phil Endecott" <spam_from_boost_dev_at_[hidden]> writes:

> Howard Hinnant wrote:
>> On Oct 30, 2007, at 2:03 PM, Phil Endecott wrote:
>>> Howard Hinnant wrote:
>>>> Actually thread cancellation is old.  Many (not all) thread API's
>>>> have some form or another of cancellation.  That being said, the
>>>> compromise reached at the Kona meeting 4 weeks ago was to remove
>>>> cancellation (or interruption) from the proposal.  This removal is
>>>> reflected in N2411.
>>>
>>> That's unfortunate.  I'm a little confused about how completely
>>> removing it is a "compromise"!
>>>
>>> This is something that I need.  Does anyone know of an alternative
>>> (POSIX-compatible) C++ thread library that offers cancellation?  If  
>>> not I may try to write one.
>>
>> A partial workaround is to religiously use cv::timed_wait, as opposed  
>> to cv::wait, so that you can wake up and discover if you're supposed  
>> to quit every once in a while.
>
> Hi Howard,
>
> Maybe you'll recall a previous message of mine where I commented on the 
> power-efficiency implications of frequent wakeups, and the benefits of 
> aligning them.  So no, I'm not keen on this approach.
>
> I would like to think that a pthreads cleanup function could be written 
> that would have the effect of invoking destructors from the 
> cancellation point up to the thread entry point.  Can you explain the 
> rationale for leaving it out?

How do you propose doing that? That would require knowing at what point the
thread was cancelled, and walking up the stack, which is therefore
implementation-specific. What about interaction with other cleanup handlers
--- how would these get interleaved?

In C++, the only ways of unwinding the stack are to throw an exception or
break out of a block with a return, break or goto statement. Are you
suggesting adding "thread cancellation" as another, or are you suggesting it
maps to an exception? If it maps to an exception, how do you handle cleanup
handlers in C stack frames on an implementation that doesn't allow C++
exceptions in C stack frames? If it doesn't map to an exception, what about
functions that do their cleanup in catch(...) clauses? If it does map to an
exception, can you catch it? Does it automatically rethrow?

These are some of the issues that have caused cancellation to be a sticking
point. I think cancellation should be a normal exception, so it can be caught
and discarded, and handles stack unwinding in a C++-like fashion, and that's
what boost.thread now does. I also think that interaction with pthread_cancel
and C stack-frame cleanup handlers is a "nice-to-have", but not
required. Boost.Thread does not interoperate with pthread_cancel.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL