Nonterminating exceptions with longjump?

Nonterminating exceptions with longjump?

[Gabor Greif]

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). The call stack won't
contain destructors, just exception handlers.

consider this (untested, pseudocode):

struct non_terminate
{
	jmp_buf resume;
};

// demonstrate throw
//
void bar(void)
{
	non_terminate exc;
	if (setjmp(exc.resume))
	{
		// do I need to call some library
		// function to end the throw?
//		__exception_complete(); // or such...

		// report it
		cout << "resuming execution" << endl;


		cout << "throwing again" << endl;
		throw exc;
	}
	else
	{
		cout << "throwing exception" << endl;
		throw exc;
	}
}

// demonstrate handler
//
void foo(void)
{
	try {
		bar();
	} catch (non_terminate& resumer)
	{
		cout << "handling exception" << endl;
		throw;
	}
}


// main routine
void thread_entry(void)
{
	try {
		foo();
	} catch (non_terminate& resumer)
	{
		cout << "resuming to thrower" << endl;
		longjmp(resumer.resume,1);
	} catch (...)
	{
		cout << "huh?" << endl;
	}
}

I understand that in order for this to work, the stack
unwinding must happen after all handlers are done
and there must be a callable function like
__exception_complete that "unhappens" the exception
but does not cut the stack. This is needed in order to
avoid "terminate" because of an exception thrown
while unwinding.

I am interested to know whether there is any chance that
this scheme does work (and keeps working in forseeable
future) with g++.

Thanks for your patience.

	Gabor

Nonterminating exceptions with longjump?

[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.

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

Andrew.

Re: 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.