[c++-pthreads] Re: thread-safety definition

[Fergus Henderson]

On 12-Jan-2004, Alexander Terekhov <boo at terekhov.de> wrote:
> > Fergus Henderson <fjh at cs.mu.oz.au> writes:
> > 
> > > When a thread gets a cancellation request, the first
> > > cancellation point encountered thereafter will act on that request
> > > (by unwinding the stack, or in Nathan's model by returning an error
> > > return status and setting errno = ECANCELLED).  If another
> > > cancellation point is encountered after that, and there has not
> > > been another cancellation request, then the cancellation point
> > > will normally not have any effect.
> > >
> > > With "sticky" cancels, after a cancellation request,
> > > *every* subsequent cancellation point will act on the cancel
> > > (by unwinding the stack, or failing with ECANCELLED).
> > >
> > > "sticky" cancels make it difficult/impossible to clean up properly,
> 
> In the current POSIX/C++ environment one must disable/restore-old
> cancellation state in the destructors that call POSIX cancellation 
> points anyway (I mean "general cancel-safe library" stuff). That 
> does ensure proper cleanup.

Yes, to the extent that there _is_ a de facto standard current POSIX/C++
environment, it does not use sticky cancels, and so it is possible to
do proper cleanup.

> David Abrahams wrote:
> > OK, thanks for the explanation.  Sounds like an argument for Jason's
> > exceptions that re-assert cancel when they're destroyed.
> 
> Making broken code a bit less broken is hardly the right design 
> rationale. Presuming that we'll get a standard named thread cancel 
> request exception,

I hope that we get a standard base class for thread cancel request
exceptions, and that we provide a way for code which requests a thread
cancellation to specify an object of any class derived from this standard
base class, and have that object (or a copy of it) be the object thrown
in the cancelled thread.

> his "fix" (with respect to broken C++ libraries) 
> is nothing but
> 
> catch(...) {
> 
>   /* ... no re-throw here ... */
> 
>   try {
>     throw;
>   }
>   catch(std::thread_cancel_request const &) {
>     std::thread_enable_cancel(); // re-enable cancel
>     std::thread_self().cancel(); // re-inject cancel request
>   }
>   catch(...) { }
> 
> }

There's a big difference between doing that automatically
and doing it manually.  If it is done automatically, you
can be sure that the programmer won't accidentally forget
to do it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.