From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 15:36:40
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:
>> 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
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
void std::this_thread::sleep(std::nanoseconds rel_time)
template<class Predicate> void std::condition<Lock>::wait(Lock&,
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).