Boost logo

Boost :

Subject: Re: [boost] Question for C++ experts aboutexception allocationfailure
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2009-05-18 09:14:34


Adam Badura wrote:
>> 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.
It does not request preallocation because the standard doesn't request
*anything* about implementation details. Storage for exceptions is an
implementation detail.
>
>> 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.
>
At the same time, it is not entirely blind to it. It does not require
anything that is impossible to do in a multi-threaded environment.

>> 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).
Here's a perfectly legal, perfectly defined C++03 program in a single
module with a single thread that has a runtime-determined number of
exceptions:

#include <iostream>

void fun(int recursions);

int main()
{
  int n;
  std::cin >> n;
  fun(n);
}

void fun(int recursions) {
  try {
    throw 0;
  } catch(int) {
    fun(recursions - 1);
  }
}

Sebastian


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