[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: block-scope finalization
- From: "Soni L." <fakedme@...>
- Date: Fri, 13 Nov 2015 16:34:02 -0200
On 13/11/15 04:23 PM, Patrick Donnelly wrote:
In Lua, you sometimes have .close(), :close(), :disconnect() and even
On Fri, Nov 13, 2015 at 11:16 AM, Soni L. <firstname.lastname@example.org> wrote:
On 13/11/15 08:19 AM, Viacheslav Usov wrote:
This may have been discussed earlier; if so, kindly point me to the
Lua uses garbage collection for everything. User-defined objects can use
metatables to perform appropriate finalization. For example, Lua's built-in
io library use the __gc field in its files' metatable to close the
underlying OS file, even if the user does not call the file:close function.
That works very well, except that finalization is non-deterministic, i.e.,
it is impossible to predict when it will happen.
Using the example of files, this may be problematic, because the file
remains open unpredictably long, which may interfere with the other uses of
the file. It could be said that if determinism is important, the user must
ensure that file:close is called. Unfortunately, taking into account that
there can be some very complicated logic between io.open and file:close,
which may also raise Lua errors, this could lead to extremely unwieldy code.
This problem is not specific to Lua and probably exists in every
GC-collected environment, so there are some established ways of dealing with
it. In C#, for example, this is done via the keyword 'using', which
establishes a scope, upon exiting which (including exiting via an
exception), the object is finalized. Example from
using (Font font1 =new Font("Arial", 10.0f))
byte charset = font1.GdiCharSet;
using(Font.new("Arial", 10.0), function(font1)
local charset = font1.GdiCharSet
Where using() runs the function in a coroutine and hooks errors in order to
finalize the font.
local function cleanup(ret)
collectgarbage() -- twice to make sure it's collected
return table.unpack(ret, 1, ret.n)
This double collectgarbage() is both expensive and evil. Don't
micromanage the collector. If your program logic relies on GC
behavior, you're doing it wrong.
How do you handle all the different ways to do that stuff? You just
force a __gc.
local f = select(-1, ...)
local co = coroutine.create(f)
local ret = table.pack(co.resume(...)) -- or something
local yielded = -- process coroutine.yield() or something
while co.status() ~= "dead" do
ret = table.pack(co.resume(table.unpack(yielded)))
local status = table.remove(ret, 1) -- remove ret, which contains the
if status then
-- process coroutine.yield() or something
errmsg = table.remove(ret, 1) -- remove ret again, which now
contains the error message
if co.status() == "dead" and errmsg then
return cleanup(ret) -- pop `...` from the call stack
A better solution might have called a required cleanup method on the
first argument of using(...). [Or even getmetatable(o):__gc()...]
Personally, I would like language support for cleanup of objects on
errors / out-of-block jumps. It's becoming an increasingly common
feature in languages: "with" in Python, "using" in C# (OP), "defer" in
Golang (which unfortunately only executes deferred calls until
return), etc. I don't like bundling error handling with
object/resource cleanup. It leads to the common situation of programs
skipping error handling ("because I want to pass the error up to the
calller anyway") and letting the GC eventually clean up the mess.
Unlike them, Lua doesn't actually need it.
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.