Nonterminating exceptions with longjump?

[Gabor Greif]

Am Montag den, 3. Februar 2003, um 14:20, schrieb Andrew Haley:

> Gabor Greif writes:
>> I have a crazy idea for a long time but I did not dare to
>> articulate it till now. I know it is not standard-conformant,
>> but I just want to know whether it would work with g++.
>>
>> I intend to simulate non-terminating exceptions on top of the
>> g++ exception handling machinery (sjlj-based or
>> table based, whatever).
>
> As I understand it, non-terminating exceptions execute some code and
> then either throw another exception or return.  Signals do the same,
> at least on systems that support throwing an exception from a signal
> handler.

 From what I remember, signals are meant to be invoked asyncronously
and their handlers are only allowed to set a volatile integer and return.
When signals are invoked syncronously they may have similar properties 
and privileges like non-terminating exceptions.

But:
Can signal handlers pass on to the next handler in the call chain?
Are signals per-thread?
Can signal handlers easily access the local variables without resorting
to nested functions (GCC extension)?
Do signals utilize fast, table-based association of handlers to return
addresses?
What is the performance-cost of registering and unregistering signal
handlers for each function body?
What is the syntactical overhead of pulling such a stunt with signals?

>
> So, in what way are non-terminating exceptions different from signals?

Depending on the answers to my above questions.

My motivation was to implement some kind of stack introspection, e.g.
- (infinite) recursion detection,
- stack marking for exact garbage collection,
- thread-global data (by acquiring a pointer to a local struct
   in the thread entry)
- etc.

These things are rather easy to do in Dylan, which has non-terminating
conditions.

In the meantime I tried my example on CodeWarrior (PowerPC, v8.3)
and I get and infinite sequence of lines on the console.
GCC 2.95.2 aborts at the "throw" after the longjmp. So I guess my 
suspicion is correct that I have to clear some flag to end exception
processing.
Tests with gcc 3.0 may come tomorrow.

>
> Andrew.
>

Thanks for your interest,

	Gabor

-- still curious knowing how I can avoid the abort() in gcc.