[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: lua_close()
- From: "John Passaniti" <jmp@...>
- Date: Fri, 5 May 2000 11:23:35 -0400
This isn't a bug in Lua itself, but in the driver program in src/lua/lua.c.
I realize that Lua was designed to be embedded in other applications, but
some folks may be using the provided Lua interpreter as an application
itself. I know I am-- Lua is a neat little language in its own right.
I notice that in Lua 4.0 (and 3.2) that lua_close() is only called if the
symbol DEBUG exists...
#ifdef DEBUG
lua_close();
#endif
Shouldn't lua_close() always be called? Under most reasonable operating
systems, the memory allocated will be freed. But memory isn't the only
resource that might be allocated. Let's say that I create an object in Lua
that represents a lock file. I would like the garbage collect method for
that object to release the lock file at the end of the program's run, but
since lua_close() isn't called, it won't.
I have a related question.
I intend to use Lua as part of a VxWorks application. VxWorks is a
multitasking real-time operating system. One of the properties of VxWorks
is that memory allocated by tasks is *not* freed when the task ends. In my
application, tasks may freely start and end as various events occur in the
system. Because of this, I need to be absolutely sure that lua_close()
does what the documentation claims it does.
Have the language designers (or anyone else) used memory-checking utilities
(like Purify, etc.) to validate that Lua cleans up completely after itself
after lua_close() executes? If so, great. If not, I guess I'll have to
give it a try myself, since I can't rely on the operating system to clean
the task up for me.