[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: customizable Lua "panic" behavior
- From: "Jim Mathies" <jamesmathies@...>
- Date: Mon, 19 Nov 2001 16:41:40 -0600
I have a similar problem, in that in Yindo, if exit is called, the browser closes.
What about using setjmp and longjmp? I've tried this with some success. In Lua
4.1, i added a jmp_buf to the state, and replaced the single exit call in ldo
- ldo.c, 322, longjmp(L->exitJmp, 1);
And i set the jmp_buf before my first call dobuffer. I haven't tested this in 4.1 yet,
but in 3.2 it worked ok. In some cases if the state was really screwed up, lua_close
would cause an exception fault. I'm wondering if with a little more safe checking
in lua_close, this would work.
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <email@example.com>
To: "Multiple recipients of list" <firstname.lastname@example.org>
Sent: Monday, November 19, 2001 7:22 AM
Subject: Re: customizable Lua "panic" behavior
| >When Lua gets into a reall bad error (one for which no error handler is
| >available) it calls exit.
| We understand that killing the host program is not very polite, but what else
| could it do when facing a real bad error? It cannot return to the application
| because the state might be unusable after a memory allocation error.
| Just to make it clear: Lua only calls exit when some error happens *outside*
| the execution of a chunk. It does not need to be a bad error at all. It might
| simply be lua_error called directly from C at the top level (that is, without
| going through Lua). It might be trying to index an undefined variable or
| something like this.
| One simple way to avoid exits is to make sure that Lua is always called inside
| an execution context, and this is simple to do by running your code as an
| ordinary Lua function. In other words, in main do whatever initialization
| is needed, including opening Lua, and then call a function to do the actual
| work using lua_pushcfunction and lua_call(L,0,0).