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.