Re: [boost] [thread] thread interruption semantics

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-11-14 09:25:19

Phil Endecott wrote:
> Beman Dawes wrote:
>> Phil Endecott wrote:
>>> Anthony Williams wrote:
>>>
>>>> The interruption points are:
>>>>
>>>> thread::join, thread::timed_join
>>>> this_thread::sleep
>>>> condition_variable::wait, condition_variable::timed_wait
>>>> condition_variable_any::wait, condition_variable_any::timed_wait
>>>> this_thread::interruption_point
>>> Am I the only one who thinks that not having cancellation points at 
>>> blocking I/O makes this fairly useless?  Perhaps I am!  I'm curious to 
>>> hear about use-cases where Anthony or Preston's proposals are appropriate.
>> The folks in the C++ committee's ad hoc thread working groups have been 
>> discussing this for the last year or so. Several points that came up in 
>> those discussions may be worth repeating:
>>
>> * For some types of I/O on some operating systems there is simply no way 
>> to interrupt a blocking I/O operation once it has started. Even 
>> rewriting the operating system itself wouldn't help for some hardware. 
>> Rewriting the operating system isn't practical, anyhow.
> 
> A balance is needed between supporting as wide a range of systems as 
> possible and not holding back everyone else.

Agreed.

> I would be happy for interruption / cancellation to be specified with 
> provision for each platform to indicate which underlying OS operations 
> are interruptible and which are not.

I don't know enough to know if that is a workable solution. We clearly 
aren't ready to standardize anything yet. So Boost can perform a 
valuable service to the wider community by developing a workable 
solution, and then putting it into use to gain real world feedback.

>> Very smart and knowledgeable designers have tried for decades to come up 
>> with really good solutions to the cancellation problem in general. They 
>> have all failed, regardless of the language involved. This is one tough 
>> problem. The only solutions that seem to work at all are the limited 
>> cooperative solutions.
> 
> What problems will a C programmer using pthread_cancel() encounter?

I don't know for C. For C++, issues like "will destructors run?" and 
"will some resources attempt to be used after they have already been 
released?". But you need to ask a POSIX expert for details.

> Are you saying that that solution doesn't work at all?

My (limited) understanding is that pthread_cancel() may have correct 
semantics on some platforms but not others, and some of the POSIX folks 
are dead set against changing the specification to ensure it supplies 
useful C++ semantics. It appears, as an example, that Mac OS X would 
have to make changes that aren't acceptable to Apple as currently 
envisioned. But the situation is murky. Clashing examples and 
counter-examples abound, and there appear to be serious non-technical 
issues.

--Beman