RE: customizable Lua "panic" behavior

["Eric Ries" <eries@...>]

I would be OK with this behavior as well:

if "panic" funciton exists, call it
if no panic function, or panic function returns, call exit()

This way, my panic funciton can decide to do some trickery if it wants to
(maybe setjmp/longjmp, maybe exceptions, maybe attempting to "fix" the
stack). If it is successful, it should not return to ldo.c but rather
somewhere else in the host program.

Does that make sense?

Eric

> -----Original Message-----
> From: owner-lua-l@tecgraf.puc-rio.br
> [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of Jim Mathies
> Sent: Monday, November 19, 2001 8:51 PM
> To: Multiple recipients of list
> Subject: Re: customizable Lua "panic" behavior
>
>
> yeah although it's a catch 22 if your code _doesn't_ call exit. You said
> you didn't want your process to end. Ultimately your exit handler has to
> return if it doesn't call exit, back into Lua which is in an
> undefined state.
> Lua calls exit as a last resort - you don't want to return to the vm and
> continue execution. That's the nice thing about setjmp, you go back to
> where you originally stored the call stack's state - which was
> prior to your
> thread ever entering the vm in the first place.
>
> Regards,
> Jim
>
> ----- Original Message -----
> From: "Eric Ries" <eries@there.com>
> To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
> Sent: Monday, November 19, 2001 9:31 PM
> Subject: RE: customizable Lua "panic" behavior
>
>
> |
> |
> | > -----Original Message-----
> | > From: owner-lua-l@tecgraf.puc-rio.br
> | > [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of Edgar Toernig
> | > Sent: Monday, November 19, 2001 6:21 PM
> | > To: Multiple recipients of list
> | > Subject: Re: customizable Lua "panic" behavior
> | >
> | >
> | > Well, then say how you want to deal with it!  You _have_ to
> set up some
> | > wrapper that catches the error and (at least) restores the C stack!
> |
> | I want to be able to call my own C function, that has the same
> properties as
> | exit (cleans up, handles the error) but does not have the nasty
> side-effect
> | of exiting my process. I'm imagining something like this:
> |
> | int defaultExitImpl( lua_State * L )
> | {
> |   exit( 1 );
> | }
> |
> | ... during lua_open ..
> | L->exitFunc = defaultExitImpl
> | ...
> |
> | Now, we add a function like lua_setexithandler( lua_State *,
> lua_Cfunction )
> | to which I can pass my own exit handler. Let's imagine this was
> stored as
> | part of lua_State as "exitFunc"
> |
> | so now, where ldo.c currently calls exit() it can now call
> |
> | (*L->exitFunc)(L);
> |
> | instead.
> |
> | Does that make sense?
> |
> | Eric
> |
>
>