Boost logo

Boost :

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.


> 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


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