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. * Experienced (and respected) users of similar cooperative interrupt facilities report that while far from perfect, these imperfect facilities are still far better and more useful than having no interrupt facilities at all. AFAICR, those comments applied both to cooperative interruption in general and the problem of blocking I/O in particular. 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. --Beman