Jason Merrill wrote:
On Tue, 13 Jan 2004 21:19:15 +0100, Wil Evers <wil@xxxxxxxxxxxxxx> wrote:
>
True, throwing out of a destructor is more likely to cause trouble thanIt is true that an exception escaping from a destructor will not trigger immediate program termination when the program/thread in question is not unwinding; however, that doesn't mean there's nothing to worry about. The most likely symptom is a resource leak; in a multi-threaded environment, that could mean a deadlock.throwing from other places; a destructor like Guard::~Guard() { write (0, "releasing", sizeof ("releasing"); release (resource); } will fail to actually release the resource if a cancel is delivered during the call to write(). It's certainly possible to restructure code to avoid this problem, but I can see this being a source of hard-to-debug problems.
The situation is actually a bit more complicated: many container implementations, including the ones in the C++ standard library, assume that the destructors of their elements do not throw. Most likely, an exception escaping from one element's destructor will cause the remaining elements to be abandoned (and not destroyed at all).
This is a somewhat persuasive case for disabling cancel during all destructors, but I'm not sure it outweighs the overhead involved. In the model I proposed, only the EH runtime needs to know about cancellation.
As I tried to say before, my main objection to your model is that, depending on the thread's dynamic context, destructors will behave differently when hitting a cancellation point. Sometimes, your model will protect us from cancellation exceptions, but at other times it won't, and I fear the confusion that might result from this.
I agree that the overhead of disabling cancellation in all destructors could become a problem. IMO, if we have sticky cancellation, the EH runtime doesn't need to be disable cancellation either.
Most destructors only deal with releasing memory anyway, and don't need to call any throwing functions. Some destructors do more complicated things, involving calls to functions that *do* throw exceptions. These destructors must take extra precautions and are harder to implement, but this has always been the case - ever since exceptions were added to C++.
The thing that changes because of cancellation is that some functions that didn't throw before will now be licensed to do so. It seems to me that most of the participants on this mailing list accept that this will require changes to existing code. That could include adding a try/catch block to destructor code.
- Wil