[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Weak tables and userdata finalization
- From: Mark Hamburg <mark@...>
- Date: Sat, 3 Sep 2011 17:16:54 -0700
On Sep 3, 2011, at 3:13 PM, Gregory Bonik wrote:
> Mark Hamburg wrote:
>> The actual case we were dealing with:
>> View system userdata objects have Lua environments to couple them into
>> the Lua logic. These point to other objects supplying values through a
>> binding mechanism. In particular, we can have value suppliers
>> supplying images which are themselves represented with userdata
>> Collecting the view data preserves its environment which preserves the
>> value supplier but doesn't keep the image being supplied from being
>> finalized. Code comes along and constructs a new view which wants to
>> find a supplier for a particular image and gets the cached which leads
>> to it try to use a finalized image.
> If I understand correctly the case, there is another problem here. It
> can happen so that the new view is allocated exactly at the same address
> as the old one. As I can conclude from you original post, you have a
> mapping (via a weak table) from the lightuserdata addresses to the env
> tables of the views.
> Suppose that GC finalizes old view's userdata but keeps its env table,
> then a new view with the same address is constructed and mapped to the
> env table of the old defunct view.
Not a problem, the table goes from light userdata (the view) to full userdata (the Lua-side proxy) and from that we go to the environment.
> I my case, I have a sort of "indirect" cache: C++ object addresses are
> mapped to env tables via a special weak table. Env tables are used to
> store Lua callbacks connected to objects. Multiple userdata can
> represent the same object, so they share the same env table. These
> userdata do not have a finalizer. Instead, a special userdata is
> referenced from each env table. Its sole purpose is to decrement C++
> object's reference count in the finalizer. Everything went fine until
> the memory allocator started to reuse disposed memory for new objects.
Yeah. We're safe from that because the existence of the non-finalized Lua proxy will keep the native object alive and the only thing we map to from the native object is that non-finalized Lua proxy.