"Phil Endecott" <spam_from_boost_dev@chezphil.org> writes:
Howard Hinnant wrote:
On Oct 30, 2007, at 2:03 PM, Phil Endecott wrote:
Howard Hinnant wrote:
Actually thread cancellation is old. Many (not all) thread API's have some form or another of cancellation. That being said, the compromise reached at the Kona meeting 4 weeks ago was to remove cancellation (or interruption) from the proposal. This removal is reflected in N2411.
That's unfortunate. I'm a little confused about how completely removing it is a "compromise"!
This is something that I need. Does anyone know of an alternative (POSIX-compatible) C++ thread library that offers cancellation? If not I may try to write one.
A partial workaround is to religiously use cv::timed_wait, as opposed to cv::wait, so that you can wake up and discover if you're supposed to quit every once in a while.
Hi Howard,
Maybe you'll recall a previous message of mine where I commented on the power-efficiency implications of frequent wakeups, and the benefits of aligning them. So no, I'm not keen on this approach.
I would like to think that a pthreads cleanup function could be written that would have the effect of invoking destructors from the cancellation point up to the thread entry point. Can you explain the rationale for leaving it out?
How do you propose doing that? That would require knowing at what point the thread was cancelled, and walking up the stack, which is therefore implementation-specific. What about interaction with other cleanup handlers --- how would these get interleaved? In C++, the only ways of unwinding the stack are to throw an exception or break out of a block with a return, break or goto statement. Are you suggesting adding "thread cancellation" as another, or are you suggesting it maps to an exception? If it maps to an exception, how do you handle cleanup handlers in C stack frames on an implementation that doesn't allow C++ exceptions in C stack frames? If it doesn't map to an exception, what about functions that do their cleanup in catch(...) clauses? If it does map to an exception, can you catch it? Does it automatically rethrow? These are some of the issues that have caused cancellation to be a sticking point. I think cancellation should be a normal exception, so it can be caught and discarded, and handles stack unwinding in a C++-like fashion, and that's what boost.thread now does. I also think that interaction with pthread_cancel and C stack-frame cleanup handlers is a "nice-to-have", but not required. Boost.Thread does not interoperate with pthread_cancel. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL