Boost logo

Boost :

Subject: Re: [boost] Question for C++ experts aboutexception allocationfailure
From: Adam Badura (abadura_at_[hidden])
Date: 2009-05-17 12:33:41


> First, the analysis to get the total size of all exceptions that could
> be active at the same time requires the dynamic call stack. This
> includes dynamic libraries. It is therefore fundamentally impossible to
> correctly determine this size.

    Obviously I meant case when you have one binary unit. So the compiler
knows everything (the system API does not throw). I doubt whether Standard
(actual) says anything about exceptions propagations between programs (a DLL
and EXE are here different programs). Inter-module propagation of exceptions
is a risky thing. It will work only in case you actually have strong control
over all those modules.
    On the other hand such propagation beyond modules indeed is used and
works. So maybe Standard did not request preallocation because in practical
cases (different binary modules) it would not work anyway.

> Second, when threading is in play, you must multiply this amount by the
> maximum number of threads ever active concurrently. This is just as
> impossible.

    Again the same. Current Standard does not deal with multi-threading.

> Third, when you have exception propagation, you can keep exceptions
> alive indefinitely. In theory, you could end every single catch block
> you have by pushing current_exception() into a global container. Thus,
> over the run time of the application you can accumulate an arbitrary
> amount of exceptions.

    AFAIK this is not true. At a single execution point we might require
space for only two exceptions (per thread). The one actually thrown and a
second one in case we are in catch block and we construct a new exception.
There is no such thing as current_exception in current Standard and the one
implemented in Boost.Exception makes a (dynamically allocated) copy. How
will current_exception be implemented in future C++ Standard implementation
I don't know.
    More exceptions would be possible if if throwing an exception while an
exception is already active would not terminate execution. The Standard
might allow throwing a second exception unless it would lead to unwinding
the same function for two exceptions at the same time. This way we could
call to throwing functions in destructors if we just did not propagate
exceptions from them. If I am not mistaken Standard does not allow it and
terminates upon throw for a second time (I don't know why this is so). So I
don't see way of achieving more then 2 exception objects at the same time
(per thread).

> So no, you can't statically determine the size you need.

    In most practical cases indeed.
    However there exist cases where such detection is possible and I think
no so hard.

    Adam Badura


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk