[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: luacom paralyzes os.exit
- From: Jonathan Castello <twisolar@...>
- Date: Wed, 3 Mar 2010 00:16:31 -0800
I think that lua_close() runs the GC, doesn't it? So if it can collect
the userdata-bound COM objects, they should be freed as long as they
have a __gc metamethod to free the COM objects themselves. That is, I
don't think it has anything to do with COM, just the garbage
collection of userdata. That would explain why your patch works.
Well, I think so, anyways. I recently wrote an interface to the json-c
library for Lua, and I had to deal with garbage collection myself, so
I -think- I'm right. But hey, if someone has to set me straight,
please do...
~Jonathan
On Tue, Mar 2, 2010 at 11:22 PM, Kenneth LO <kenlo88@gmail.com> wrote:
> So lua_close is the problem. Just a quick change to loslib.c
>
> static int os_exit (lua_State *L) {
> int t = luaL_optint(L, 1, EXIT_SUCCESS);
> lua_close(L);
> /* exit(luaL_optint(L, 1, EXIT_SUCCESS)); */
> exit(t);
> }
>
> So far it does the job but I'm not sure if there is any memory
> leakage. The manual says it will free all memory associated with the
> state but does it include those locked in COM and OLE? In comparison,
> the php manual explicitly says that an exit() will free all memory and
> object destructors will always be executed. I tried to find out how
> it was implemented from the php source. But then I gave up.
>