Re: Re[2]: state of the Lua nation on resource cleanup

[Cosmin Apreutesei <cosmin.apreutesei@...>]

On Mon, Jun 1, 2009 at 00:58, Peter Cawley <lua@corsix.org> wrote:
> On Sun, May 31, 2009 at 10:42 PM, Cosmin Apreutesei
> <cosmin.apreutesei@gmail.com> wrote:
>> With immediately-collected resources, the functionality of f:close()
>> remains, as replaced by f = nil. I don't think any control is taken
>> away.
>>
>
> Expect "f = nil" would not provide the solid guarantee that the
> resource was collected, whereas "f:close()" does. Consider the example
> of a database API which only allows one (non-closed) cursor to exist
> at any one time. After running a query and using a cursor to iterate
> the results, you want to be absolutely sure that the cursor is
> collected, as otherwise no other database calls will work. If you
> accidently make a copy of "f" to some place, then "f = nil" would not
> collect the cursor, and your application would start failing all over
> the place. Using "f:close()" would guarantee that the cursor is
> closed, and any further operations on this one cursor object would
> result in a Lua error, which is (IMO) a much better result than having
> the rest of the application's future DB interactions failing.

But that's a feature any library could provide if so designed. That
database API would surely have a close() method. And if it doesn't,
you could encapsulate the handler with a few lines of lua code and
provide the close() method yourself.

>
> Also, as already stated, implementing immediately collected resources
> would impose an overhead on every local variable assignment and table
> write.
>

I don't understand lua's implementation enough to have an opinion on that.