Re: [boost] Comments about N2320

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-01 19:16:09

Hi Anthony,

Anthony Williams wrote:
> "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.

[answering your other mail first]
> By "POSIX-compatible" do you mean "works with and uses pthread_cancel", or do 
> you mean something else? It's the interaction with pthread_cancel that caused 
> the biggest sticking point, as I understand things.

Sorry, I was being inaccurate.  What I should have said was that I'm 
writing Linux code, so I need a library that will work on Linux.  Being 
implemented on top of the pthreads functions would be one solution.  
No, I don't need to mix C++ destructors and C pthread_cleanup.  Of 
course a cross-platform solution would be essential for a standard 
library and very highly desirable for a Boost library, but I need a 
solution "real soon now"!  Hence my enquiry about any other libraries 
that people might know about.

>>> 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?

Yes, you need lots of implementation-specific stuff.  My guess is that 
the pthread_cleanup function is in practice executed with the cancelled 
thread's stack, so you can find the starting point for stack-unwinding 
just above the current stack pointer.  Maybe you can even just "throw 
Cancelled();" from a pthread_cleanup function!  But that's just a guess.

> 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 does map to an
> exception, can you catch it? Does it automatically rethrow?

I don't care about any of this for my current application, though I 
have always imagined it mapping to an exception.

> 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.

Yes, I agree with all that.

Clearly there are various choices about how cancellation should behave, 
with various pros and cons, and many questions about the practicalities 
of implementation on different platforms.  Certainly the standards 
committee have investigated these issues.  I would very much like to 
have some insight into what they discovered during their 
investigations, leading them to their decision to not offer any sort of cancellation.

Regards,

Phil.