[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: state of the Lua nation on resource cleanup
- From: Geoff Leyland <geoff_leyland@...>
- Date: Wed, 11 Feb 2009 17:47:40 +1300
I've got a project where I use pcall often to catch "errors" that are
generated with error() when inconsistencies in data being read are
found. I think it's a reasonable use of error/pcall (rather than, say
passing back an error code through the chain of data reading
functions), but it's not a case where enough has gone wrong that any
resources are left hanging, so I don't need or wish for a full garbage
collection and finalisation. I know nothing about the cost of such a
collection, so I can't say whether I'd rather not have one.
On 11/02/2009, at 12:07 PM, Roberto Ierusalimschy wrote:
Besides opinions from the community, I'm hoping for some word from
Lua authors like one of "working on a solution", "Lua doesn't need
improvement here", "see the need for it but don't have a design in
Later on this discussion David Manura wrote:
Now, personally, in practice, I've only found myself wanting this
of capability in Lua on a few occasions (but perhaps others with
different applications will have greater need for it):
- closing file handles upon exceptions
- closing COM objects on exceptions
- releasing native OS handles on exceptions, e.g. as once in
- and if I used Lua more for database and socket work, quite
possibly that too.
I personaly agree with him. In all cases the key point is "on
He then goes on:
Workarounds I've used are explicit collectgarbage() calls judiciously
placed, adding pcalls (often ugly, affects error tracebacks, and can
conflict with coroutines), and ignoring the problem (sometimes
Maybe we could avoid these workarounds by forcing a full garbage
upon errors. This could be added to the core or through the libraries.
(That is, pcall and other library functions that do protected calls
call lua_gc in case of errors, and user's C code would be recommended
to do the same.)
That is, all resources should have an explicit "close" method plus
a finalizer that releases it. (Like files from the io library.) In
regular use, the control flow should call the close method for prompt
release. On exceptions, a full collection would call the finalizers.
If needed, we could add to the library a "generic resource":
a = newresource(func) -- creates something
a:close() -- calls 'func'
If 'a' is collected before being closed, its finalizer calls 'func'.