lua-users home
lua-l archive

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

On Sat, May 30, 2009 at 4:19 AM, Cosmin Apreutesei wrote:
>> That being said, I'd dare making a proposal that I've been giving some
>> thought, maybe I can hear your opinions about it (well, aside from the
>> trouble it would mean to implement it): how about an __immediate_gc
>> metamethod that would ensure finalization of a table or userdata when
>> the last reference goes out of scope.

On Sat, May 30, 2009 at 4:51 AM, Bulat Ziganshin wrote:
> you can't work this way with external resources. imagine for example
> that your program opens files and process it some way. if file will be
> not closed until gc/exit, user trying to remove this file from other
> program will got unexpected fail

Cosmin's proposal though is to extend Lua to support both tracing
garbage collection and deterministic destruction, with the latter done
through reference counting.  The choice between the two would be
selectable per object, depending on the metamethod defined on the

Reference counting is one way to achieve deterministic release of
resources.  However, it is not the only solution [1].  Perl supports
the reference counting approach.  Some implementations of Python
support it too (C not Java [2-3]), but it is an implementation
decision, and the more portable method is to use the with statement
[4], which is similar to the proposals made for Lua, where resources
are released simply upon scope exit, irregardless of reference counts
(which in a correct program normally should be zero upon scope exit).

>> But that breaks garbage-collecting semantics, which assures me never
>> to have invalid pointers no matter what... IMHO this brings me back
>> down to the C-level of responsibility (watching the stack).

Even reference counts have their limitations (e.g. cycles [3]), and
you are not prevented from doing dumb things like setting the variable
to nil and then trying to access the variable or accidentally storing
the resource in a global variable, which prevents the resource from
being released upon scope exit as might be assumed happens (thereby
only hiding the error).