* Nonterminating exceptions with longjump?
@ 2003-02-02 23:07 Gabor Greif
2003-02-03 13:20 ` Andrew Haley
0 siblings, 1 reply; 3+ messages in thread
From: Gabor Greif @ 2003-02-02 23:07 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Nonterminating exceptions with longjump?
2003-02-02 23:07 Nonterminating exceptions with longjump? Gabor Greif
@ 2003-02-03 13:20 ` Andrew Haley
2003-02-04 1:16 ` Gabor Greif
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Haley @ 2003-02-03 13:20 UTC (permalink / raw)
To: Gabor Greif; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Nonterminating exceptions with longjump?
2003-02-03 13:20 ` Andrew Haley
@ 2003-02-04 1:16 ` Gabor Greif
0 siblings, 0 replies; 3+ messages in thread
From: Gabor Greif @ 2003-02-04 1:16 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-02-04 1:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-02 23:07 Nonterminating exceptions with longjump? Gabor Greif
2003-02-03 13:20 ` Andrew Haley
2003-02-04 1:16 ` Gabor Greif
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).