Phil Endecott wrote:
Beman Dawes 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
Phil Endecott wrote: 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