Re: [c++-pthreads] Re: thread-safety definition
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> > This cannot happen if cancellation is automagically disabled during
> > execution of (all) destructors, along with the stack unwinding code
> > that is performed during exception processing.
> 
> If all cleanup is done via destructors (or pthread_cleanup_push,
> which can be handled similarly), you are right.
> 
> But recall that in Nathan's model, Posix functions that return status
> values will indicate cancellation by returning a failure status and
> setting errno to ECANCELLED.  In this situation, cleanup actions will

I consider that a bad model.  (1) It is inconsistent with current
POSIX/Unix threads standards and practice, and so unlikely to get
vendor buy-in. (2) It makes it too easy for an application to
lose/forget/ignore cancellation.  I'm assuming cancellation will
*only* be reported via an exception.

> often be performed directly, rather than via destructors.  Once some
> code has called a cancellation point that fails with ECANCELLED, there is
> no way for the implementation to tell whether any further code which is
> executed is cleanup code or just a resumption of the thread's main loop.
> For cleanup code, cancellation must be disabled, so that the cleanup
> code can perform I/O to release resources.  But for any long-running
> non-cleanup code, cancellation must be reenabled; otherwise, we would
> be failing to provide the limited assurance that cancellation will not
> be accidentally ignored, which stickiness of cancellation was intended
> to ensure.
> 
> Since the implementation can't tell, the code must be modified to
> explicitly enable and/or disable cancellation at appropriate points.
> 
> Nathan's model was intended to preserve existing code that propagated
> error returns, and that did not expect functions like read() or printf()
> to throw exceptions.  However, because of the problems described above,
> such existing code would still need to be changed to make cleanup work
> properly.  So I don't think Nathan's model achieves his intended aim.

Yes.

> -- 
> Fergus Henderson <fjh@xxxxxxxxxxx>  |  "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.

--Ted