Re: Userdata finalization order

[Luis Carvalho <lexcarvalho@...>]

<snip>
> The problem that I've got are:
> - for table with weak keys the key object are not removed when they
> are finalized but
>   only at the following GC cycle => a Lua modification was needed
> - during the lua_close all the userdatas are finalized in reverse
> creation order. This can cause
>   a segmentation fault because when the plot if deallocated it does
> query its graphical
>   elements to know if they are Lua allocated or not. It does need to
> make this query because
>   the Lua object are embedded in a arbitrary long chain of C++ objects
> allocated on heap.
>   Each of this object represent a graphical transformation like
> stroking or making a dashed
>   line or things like that. The C++ allocated objects need to be
> deallocated with "delete" while
>   the Lua allocated object should not because Lua manage its allocation.

I think you should consider following Wesley and others's advice. Here's my
advice, also along the lines (sorry for the pun) of what was proposed:

- Use an environment for your plot objects and store all referenced objects in
  it;
- Only free ("delete") C++ objects in their respective __gc call

Something like this (in Lua, but you get the idea):

local setenv, getenv = debug.setfenv, debug.getfenv
local name = setmetatable({}, {__mode == "k"})
local gc = function(o)
  print("free: " .. name[o]) -- only free objects in their __gc
end 

local ul = newproxy(true)
getmetatable(ul).__gc = gc
function newline (lname)
  local l = newproxy(ul)
  name[l] = lname
  return l
end

local up = newproxy(true)
getmetatable(up).__gc = gc
function newplot (pname)
  local p = setenv(newproxy(up), {}) -- create env
  name[p] = pname
  return p
end
function addline (p, l)
  getenv(p)[l] = true -- store in env
end 

Cheers,
Luis


-- 
Computers are useless. They can only give you answers.
                -- Pablo Picasso

-- 
Luis Carvalho (Kozure)
lua -e 'print((("lexcarvalho@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'