Boost logo

Boost :

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?



Boost list run by bdawes at, gregod at, cpdaniel at, john at