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

[Alexander Terekhov <boo@xxxxxxxxxxx>]

David Abrahams wrote:
> 
> Fergus Henderson <fjh@xxxxxxxxxxx> 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).
> >
> > "stick" 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.

> > since cleaning up may involve doing I/O, and in particular by calling
> > functions that Posix specifies are cancellation points.  These functions
> > will fail to do the I/O, because they will instead attempt to act on
> > the cancellation again (i.e. re-raising the cancellation exception
> > or failing with ECANCELLED).
> 
> 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, 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(...) { }

}

(unless I'm just missing and/or misunderstanding something).

I don't think that the standard should mandate that. The 
standard should mandate mandatory 2-phase ES and intelligent
cancellation points plus async-cancel regions, of course.

regards,
alexander.