 |
lua-l archive |
|
|
||
|
Reminder: This is part of the conversation resulting from the request that the cach statement used by lua when compiled as C++ be changed to avoid catching the main application's exceptions.
Continue below:"Sam Roberts" <sroberts@bycast.com> wrote in message news:20060801170134.GE18462@pebble...
On Tue, Aug 01, 2006 at 12:51:48PM -0400, Joe Smith wrote:"Joe Smith" <unknown_kev_cat@hotmail.com> wrote in message news:eagvcd$m9n$1@sea.gmane.org... > >"Mark Hamburg" <mhamburg@adobe.com> wrote in message >news:C0F144E9.48687%mhamburg@adobe.com... >>If you do that, I think it will probably leave the Lua state messed up. >> >>Mark > >Concurred. However, that is for the end user to deal with. Enigma, >the project in which I noticed that catch statement has reasons to do >this, and in all such cases will discard the lua state, automatically >assuming it is corrupted beyond repair.Is it possible to be corrupted badly enough that it can't be closed?
Remember that the use case here is: C++ program (this has the exception handler) Lua script (executed by c++ program) C/C++ function (called by lua script) throws exception. Lua will probably be left in the state it was in, which is to say. a script in running, waiting for a C/c++ function to return. Needless to say that function will not be returning. IT should be possibleto clean up the lua state, but it easier just to close it, open a new one, and re-initalize.
It is a much bigger problem if the exception gets caught by lua. The C++ program would be left in a mostly consistant state, but memory leaks are nearly certain to result.
And aren't memory leaks also possible?
Closing a lua state should cause Lua to free any memory in use by that state. So I would be much more worried about the longjmp lua uses for internal errors. Longjmp is easy to use in a way that causes memory leaks. All too easy.
And there is a possibility that c++ app may leak memory, but that is the application's problem, and is always possible when using exceptions.