lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

>>The trouble with this approach is the contract between Lua and C regarding
>> memory management becomes very complex, and any issues with any C code
>> inevitably lead to nasty hard
>> to find crashes in Lua.
> Would it really become very complex? I'm not so sure.

I'm not sure either, but my initial feeling it would be. Writing the
memory management for LuaCocoa was very tricky/complicated. I sat down
in advance several weeks designing it on paper to handle all the
permutations. There were so many issues, I couldn't keep track of them
in my head.
- Objects crossing into Lua from Obj-C
- Objects crossing into Obj-C from Lua
- Objects that cross the bridge multiple times (say recursively)
- What to do when you subclass Obj-C classes in Lua
- Don't accidentally create retain cycles for Obj-C which it can't handle
- Also deal with the optional Obj-C's garbage collector which most
other Cocoa bridges never resolved
- And since then Obj-C blocks (closures) have complicated the memory
model even more and now that I support bridging blocks and Lua
functions, things get even tricker.

The one thing I kept finding myself constantly grateful for was Lua's
very simple and straightforward memory management system. The
predictability/consistency of the memory system (such as getting a
simple __gc callback when the object collects from Lua) really helped
me pull off all the above. And I didn't have to spend tons of time
debugging. (And yes, memory management works very well in LuaCocoa
including edge cases and it works just as you expect when in each
respective world (Obj-C or Lua)...principle of least surprise. I
attribute this success to Lua's memory design.)

An aside, the Squirrel language which is an offshoot of Lua which
intended to provide more manual memory did they go
about it, and what are the pros/cons in practice now that it has
actually been done?

Beginning iPhone Games Development