Re: state of the Lua nation on resource cleanup

[John Belmonte <john@...>]

Roberto wrote:
> Maybe we could avoid these workarounds by forcing a full garbage collection
> upon errors. This could be added to the core or through the libraries.
> (That is, pcall and other library functions that do protected calls should
> 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.

Hi Roberto.  I'm concerned about some negative consequences this
solution would have:

    * negation of incremental GC benefits - the point of the
incremental garbage collector is to minimize wost-case collection
cycle duration.  Apps relying on this would be back to square one
should an exception occur at any time (e.g. a video game might miss
its frame deadline).  I agree with the view that exceptions should not
be used lightly (my metric is to use them when an error is likely to
propagate two call frames or more), but I don't think we want to get
in a situation where a class of apps which could use exceptions
previously must now avoid them at all cost.  This is more pressure on
module providers to not use exceptions (if issues with pcall and
coroutines weren't enough).

    * difficulty for Lua implementations - there are a number of Lua
VM implementations (e.g. Kahlua) which rely on the native GC of some
particular language rather than porting Lua's memory management.
These are compelling because you can write a Lua VM and standard libs
implementation in 2K lines of code, eliminating any C lib dependency
and allowing trivial binding between native functions and the Lua
environment.  While they may miss some details of the Lua spec
regarding GC-- and so are not quite Lua-- having a finalization
solution depend on the garbage collector will widen the gap (that is,
add to their list of non-compliance).

Besides these, I think this solution overlooks the usefulness of
having a cleanup mechanism that covers all exit cases.

--John