Re: [boost] Comments about N2320

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-02 04:05:38

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

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

I added better cancellation to boost thread yesterday. condition
wait+timed_wait, thread join+timed_join, sleep and
this_thread::cancellation_point are now all cancellation points on pthreads
and windows. This uses a thread_cancelled exception, and does not interoperate
with pthread_cancel.

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

N2420 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2420.pdf)
covers some of the relevant ground --- it's the minutes of the POSIX/C++
liaison committee.

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