[boost] Re: Threads & Exceptions - Safety Verification

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-16 10:44:02

You can write a test application simple enough. I don't see how it could be
allocated on the stack when the stack is going to be immediately unwound,
but I'll take your word for it.

It doesn't matter at this point. I certainly don't want to depend on luck
when there's other ways to do it.

----- Original Message -----
From: Carl Daniel
Newsgroups: gmane.comp.lib.boost.devel
Sent: Friday, 2002:August:16 11:23 AM
Subject: Re: Threads & Exceptions - Safety Verification

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:051001c24533$8b18eb70$1800000a_at_soy...
> What resources are leaked? Of course I'm making a big assumption about how
> the compiler behaves under the hood, but, since it clearly _has_ to create
a
> duplicate instance of an exception that is thrown, on the heap, there is
no
> other way it would implement the exception.

HAS to?  I think not.

A) the compiler doesn't HAVE to make a copy of the exception at all.  For
example, if  your code were compiled with MSVC, the exception object will
most likely be allocated in the stack of the throwing thread (and NOT copied
at all).  Even if the implementation does copy it, there's nothing in the
standard that says it copies it into an object allocated from the heap
(indeed, such an implementation would be foolish, since heap exhaustion
causes an exception throw).

B) What resrouces?  Who knows!  The point is, the implementation is free to
have allocated anything it wants to between the throw point and the catch
point, and the implementation is responsible for freeing those resources -
when (and only when) the exception is handled via a normal exit from a catch
clause.

"Eric Woodruff" <Eric.Woodruff_at_[hidden]> wrote in message
news:052a01c24534$9fc021a0$1800000a_at_soy...
> Would a runtime analyzer like Rational Purify, etc, detect a leak if there
> was an implementation that didn't take the assumed path? If so, the
example
> can be proven unequivocally to either work or not work. Yes from a
language
> standpoint, it is mal-formed code, but not from a practical perspective.

There's no telling.  Any resources allocated by the implementation during
throw -> catch processing are outside the bounds of the C++ language
definition.  They may not even be allocated by mechanisms that are
accessible outside the exception propagation mechanism.

You can make your technique portable by copying the exception onto the heap
yourself in the catch clause, but since std::exception doesn't define a
virtual clone() member, such copying will be problematic at best.

-cd

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost