Re: [ANNOUNCE] Objective Lua

["E. Wing" <ewmailing@...>]

On 10/6/09, Mark Hamburg <mark@grubmah.com> wrote:
> On Oct 5, 2009, at 6:15 PM, E. Wing wrote:
>
>> Meanwhile, I patched the existing legacy bridge to be garbage
>> collection aware and fixed up some major memory leaks.
>
> Dueling garbage collectors are generally a pain. On Lightroom, we
> found it advantageous to be using the reference counted version of
> Objective-C with Lua's garbage collector. Did you actually come up
> with a reasonable way to handle the Lua object A points to Objective-C
> object B which points to Lua object A case? In a simple dual GC
> implementation (e.g., using refs or the equivalent to refer to Lua
> objects), the objects end up as roots because of the foreign
> references and the collectors end up waiting for the other to go first
> in breaking the cycle. Lightroom uses the reference count information
> to detect when the only reference to an Objective-C object is from the
> Lua side and change its handling at that point.
>

No, sorry, I didn't mean to misrepresent it. it's the most naive thing
you can imagine. It's not well tested and I wouldn't be surprised if
there are still problems like the one you describe.

Basically, I just place CFRetain's/CFRelease's in critical spots in
the bridge to make sure created lua objects don't get collected from
underneath you.

I made all these changes at the same time I was fixing normal non-gc
code. There was a bug in the bridge that expected metamethods to be
called for light user data so things were leaking. I basically moved
things over to use full userdata in a way that made the least
resistance with the current code.

One thing I have been thinking about is some kind of global map to
hold all and easily retrieve bridge objects in C before crossing the
bridge. This was not for memory management, but to avoid a uniqueness
and equality problem. I think as it is, if an object goes through the
bridge multiple times, the bridge creates a new userdata wrapper so
simple lua equality checks don't work the way you expect. And I don't
think I got the __eq metamethod working due to the peculiar way it was
implemented in the specific bridge implementation. (As I said, my
changes picked the path of least resistance.) But now you got me
thinking that I may want to expand on this idea for dealing with
memory management.

-Eric