lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.