On Mar 26, 2007, at 3:16 PM, Roland Schwarz wrote:
Howard Hinnant wrote:
layer (and that has been my sense from the boost community as well: "I want boost + cancellation").
May I drop in an innocent (or blaspheming?) question?
Please do! :-)
Why do we want cancellation?
Good question. It is part of the pthreads model and has been requested a lot from clients of boost::thread. It arguably (and I didn't realize this at first) provides the needed semantics of ~thread(): thread::~thread() { if (joinable()) { cancel(); detach(); } } I.e. if the parent thread leaves the room unexpectedly, what do you want to happen to the child thread? boost::thread simply detaches. And upon reflection, I think that can delay resource cleanup of the child thread for an unreasonably long time.
Which kind of cancellation do we want (if at all)?
In pthreads vocabulary: only deferred. Nobody even wants to talk about asynchronous cancellation. But some, because of the pthreads history, would prefer us to use a different name for "cancel" so that there is no such confusion.
Do we really need true async cancellation, or suffices to be able to control a thread at certain (well defined) points.
<nod> Only the latter.
Wouldn't 90% of the users be happy if they just be able to instruct a thread to stop while it is in an (idling) wait loop without need to resort to custom (boiler plate) IPC mechansims?
That is essentially what we're after. N2184 recommends very few cancellation points: • void std::this_thread::cancellation_point() • void std::this_thread::sleep(std::nanoseconds rel_time) • void std::thread::join() • void std::thread::operator()() • void std::condition<Lock>::wait(Lock&) • template<class Predicate> void std::condition<Lock>::wait(Lock&, Predicate) • bool std::condition<Lock>::timed_wait(Lock&, std::nanoseconds) • template<class Predicate> void std::condition<Lock>::timed_wait(Lock&, std::nanoseconds, Predicate) N2178 has the same outlook but recommends considerably more cancellation points (the entire posix set if I understand correctly). -Howard