[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: __gc and userdata order of collection issues
- From: "Wesley Smith" <wesley.hoke@...>
- Date: Thu, 9 Oct 2008 18:09:27 -0700
There was a thread not too long ago regarding the issue of the order
in which __gc is called on userdata. The manual states:
"At the end of each garbage-collection cycle, the finalizers for
userdata are called in reverse order of their creation, among those
collected in that cycle. That is, the first finalizer to be called is
the one associated with the userdata created last in the program. The
userdata itself is freed only in the next garbage-collection cycle. "
but I wonder if this condition is sufficient. It was mentioned in the
thread that Lua 5.2 might end up going off of the order in which
metatables are attached to an object instead of being based on
creation. Here's an example:
local udata1 = Udata()
local udata2 = Udata()
local filename = "path/to/file.lua"
function udata1:closing()
udata2:serialize(filename)
end
Now let's say that the script is closed via lua_close(L) and that
udata1's __gc metamethod calls udata1:closing(). In the current
version of Lua, the variable udata2 will be invalid because it will be
collected before udata1 despite udata2 being an upvalue in udata1's
closing function. Would it be possible to handle such a case with a
few tweaks to Lua or is situation too tricky to bother dealing with?
It seems somehow logically inconsistent that userdata as upvalues in
functions wouldn't be collected as long as the function exists while a
script is running, but suddenly when the script is closed the fact
that it is an upvalue in a function has no bearing on the order of
collection. The basic reference diagram looks like:
getfenv(udata1)[closing] -> a function with udata2 as an upvalue
so wouldn't the GC be able to tell that udata2 is referenced (at root)
with udata1 and be able to collect that first.
thanks,
wes