[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Weak tables and userdata finalization
- From: 冶晶邓 <fatfatson@...>
- Date: Mon, 5 Sep 2011 23:00:30 +0800
hi, mark & Gregory ~
maybe i have the similar problem with you..
i also use a weak table to save the map between c++ object address to its lua table,
every c++ object is represented as a lua table, whose array part element is a userdata for saving the c++ object's address,
and the __gc method for the userdata is set for calling the object's ref-counter decrease
at most time it goes well, but if i adjust the gc parameter "setpause" to a little value, some strange crash would happen, and the dump looks like a memory corrupt.
i have no much knownodge about lua gc, so what's your conclusion for the problem? is my c++ bind solution correct ?
2011/9/4 Mark Hamburg <email@example.com>
On Sep 3, 2011, at 3:13 PM, Gregory Bonik wrote: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.
> 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.
>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.
> 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.