Jason Merrill wrote:
I think I disagree, at least philsophically, with the characterization of the model as "fragile". But I think I also understand what you mean; and the problem isn't with the model, but rather with the effect of that model on existing code that all-too-casually and agressively eats exceptions it doesn't understand. I think there are vanishingly few circumstances where a blind catch(...) without an unconditional re-throw should be considered "legitimate". If you don't completely understand what an exception means, you cannot claim to have completely recovered, and therefore cannot reasonably finalize propagation. (And when you catch anonymously, you can't possibly understand what they mean since you can't even identify them.) On the other hand, regardless of whether the semantics are meaningful or reasonable, the syntax is legal and apparently (unfortunately) in common use, so I can't dispute that you need to consider that.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 hereMy 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.
While I didn't have anything specific in mind, just a general concern, one example that occurs to me is "catch(...) {...; throw;}". One must be careful about specifying the "cancelled" state of the thread here; it shouldn't be possible to consider the exception destroyed during the body of the catch prior to the re-throw. I don't know if the current wording in the standard would allow this interpretation: but for "traditional" exceptions that have no "state" it shouldn't really matter, and it seems plausible that the standard doesn't tie this down explicitly. (It's enough in practice that the 'throw' continues propagation "as if". Now, though, the distinction might become critical.)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 ());
-- /--------------------[ David.Butenhof@xxxxxx ]--------------------\ | Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/