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
- To: Dave Butenhof <David.Butenhof@xxxxxx>
- Subject: Re: [c++-pthreads] Re: thread-safety definition
- From: Jason Merrill <jason@xxxxxxxxxx>
- Date: Fri, 09 Jan 2004 21:41:14 -0500
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