[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: tolua++ porting to 5.2
- From: Jay Carlson <nop@...>
- Date: Mon, 14 Jan 2013 19:33:25 -0500
On Jan 14, 2013, at 1:30 PM, Tim Mensch wrote:
> On 1/14/2013 3:25 AM, Joop Boonen wrote:
>> I wonder if tolua++ could be a part of lua?
>> It's not supported any more and it's still quite widely used.
>
> I can't recommend tolua++ to anyone; the core architecture they use for binding objects is profoundly broken, as I detailed in a previous message [1].
Quick summary: tolua++ is suitable if you can guarantee the lifespan of each C-side object is always longer than the Lua-side lifespan. Otherwise you get heisenbugs. And this is a hard guarantee to make.
"Never free anything until exit" has this property, and so does "Lua lifespan determines C lifespan"--but that is difficult to arrange for unless your objects do not reference other objects.
Disciplined programmers who "know" when a reference should not be held can cover for this in the short run. The LuaFLTK binding I did back in the 4.0 era depended on smart programmers who never screwed up, but I had not realized the extent until Tim pointed it out.
The fix for this would involve C-side deallocation turning Lua-side references into tombstones, and I don't see an obvious way to implement tombstones other than something that works out to be Tim's serial numbers.
I have no idea how other general binding systems deal with the lifecycle mismatch problem, especially in the presence of reachability through member variables--somebody can squirrel away a reference to the Point in your Circle.
LuaJIT ffi's philosophy is "we suck just as much as C"--in other words, it does not attempt to solve this for you, rather than get it wrong.
Jay
> [1] http://lua-users.org/lists/lua-l/2012-12/msg00601.html