Re: [boost] [thread] thread interruption semantics

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-11-14 07:19:33

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.

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.

> 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?  
Are you saying that that solution doesn't work at all?

Regards,

Phil.