Re: [c++-pthreads] cancellation points report failure

[Fergus Henderson <fjh@xxxxxxxxxxx>]

On 19-Dec-2003, David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> wrote:
> Ted Baker <baker@xxxxxxxxxx> writes:
> 
> > How do you propose to prevent cancelation occurring (i.e., the
> > thread starts executing the cleanup routines and then exits) if a
> > C++ library function uses an underlying C library call that is a
> > thread cancelation point?
> >
> > Are you figuring on redoing all the libraries to avoid calls
> > to such C functions?
> 
> One of us is very confused.  What you're talking about is the problem
> we have today.  IIUC, Nathan was suggesting that read() should report
> cancellation using the same means it uses to report failures to 'C'
> programs, IOW, not by throwing an exception.  Maybe I've
> misunderstood something?

I understood Ted Baker's comment to be a reply to Matt Austern's "perhaps
overly drastic" suggestion that in C++, pthread_testcancel() should be
the only cancellation point, not to Nathan's alternative proposal.

I don't think Matt Austern's suggestion is workable, because defining
the semantics of system calls to be different in C++ than in C would
be much too confusing.  Ted Baker's comment above is elaborating on
one of the consequences of this.

> >> >[Matt Austern:]
> >> >> One possible solution (perhaps overly drastic): in C++, eliminate
> >> >> all cancelation points except for pthread_testcancel.
> >> >
> >> [Nathan:]
> >> > Another would be for those functions identified as cancellation 
> >> > points to report failure.  In particular, a read() call should return 
> >> > immediately.  Existing (good) code has to handle normal failures 
> >> > already.  Well-designed library code will propagate the failure up 
> >> > to the point where a check for cancellation, and throw, may occur.  
> >> 
> >[David Abrahams:]
> >> Ingenious!  I'm not sure about all the implications, but I think we
> >> should explore this idea further.  In hindsight, it's almost obvious:
> >> a function should only report failure in one way.  Requiring
> >> programmers to deal with exceptions *and* failure status makes the
> >> whole thing unwieldy and error-prone.

If we were to toss out concerns about backwards compatibility, I'm sure we
could come up with better solutions.  But backwards compatibility is
important.  And Posix already specifies the semantics of system calls
to be such that they report different kinds of failure in different ways.

-- 
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.