lua-users home
lua-l archive

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



On May 31, 2009, at 5:58 PM, Peter Cawley 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.

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


There's a more general semantic disconnect if you consider that the
close operation could fail.  I suppose in the "f = nil" case, an
exception could be thrown vs. returning some sort of error indication.

Louis Mamakos