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



On Fri, 09 Jan 2004 07:20:18 -0500, Dave Butenhof <David.Butenhof@xxxxxx> wrote:

> Jason's model, putting together the puzzle pieces from various messages
> here

My original formulation is at

  http://www.codesourcery.com/archives/c++-pthreads/msg00059.html

> , appears to be basing cancel on an ordinary ("finalizable") C++
> exception, which would be raised by any and all cancellation points; but if
> the exception object were to be destroyed (by finalization), the "pending
> cancel" would (might?) be reasserted. I personally feel that it ought to be
> reasonable to finalize the cancel and continue operation. If that wasn't
> really what the application intended then it's an application error; but
> there are cases where it's arguably reasonable, and the capability falls
> naturally out of the model.

Too naturally, IMO.  There seems to be a substantial amount of C++ code out
there which traps and finalizes all exceptions, some of it in the C++
standard library I/O classes.  I disagree with this design, and propose to
change it in the message cited above, but it's just one example.  I don't
think it's reasonable for a cancellation request to be silently discarded
just because the thread was in the middle of doing some formatted output
when the cancel was received.

I wouldn't object to a facility for explicitly abandoning the cancel, but I
think that allowing it to fall out of the model is far too fragile.

> Besides, "reasserting cancel" in all the right places and no other places
> sounds like one of those projects that ends up being a lot more subtle
> and error-prone than anyone ever expects. ;-)

Assuming support for abanoning the cancel, why would it be more complex than

  pthread_cancel (pthread_self ());

?

Jason