Hi Anthony, Anthony Williams wrote:
"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.
[answering your other mail first]
By "POSIX-compatible" do you mean "works with and uses pthread_cancel", or do you mean something else? It's the interaction with pthread_cancel that caused the biggest sticking point, as I understand things.
Sorry, I was being inaccurate. What I should have said was that I'm writing Linux code, so I need a library that will work on Linux. Being implemented on top of the pthreads functions would be one solution. No, I don't need to mix C++ destructors and C pthread_cleanup. Of course a cross-platform solution would be essential for a standard library and very highly desirable for a Boost library, but I need a solution "real soon now"! Hence my enquiry about any other libraries that people might know about.
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?
Yes, you need lots of implementation-specific stuff. My guess is that the pthread_cleanup function is in practice executed with the cancelled thread's stack, so you can find the starting point for stack-unwinding just above the current stack pointer. Maybe you can even just "throw Cancelled();" from a pthread_cleanup function! But that's just a guess.
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 does map to an exception, can you catch it? Does it automatically rethrow?
I don't care about any of this for my current application, though I have always imagined it mapping to an exception.
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.
Yes, I agree with all that. Clearly there are various choices about how cancellation should behave, with various pros and cons, and many questions about the practicalities of implementation on different platforms. Certainly the standards committee have investigated these issues. I would very much like to have some insight into what they discovered during their investigations, leading them to their decision to not offer any sort of cancellation. Regards, Phil.