RE: Feature request: more integration of Lua and C memory management

["Bilyk, Alex" <ABilyk@...>]

>-----Original Message-----
>From: Jamie Webb [mailto:j@jmawebb.cjb.net]
>Sent: Wednesday, June 09, 2004 6:59 PM
>To: Lua list
>Subject: Re: Feature request: more integration of Lua and C memory
>management
>
>
>On Thursday 10 June 2004 01:39, Bilyk, Alex wrote:
>> Well, the post you are referring to outlines some real 
>problems. However,
>> even though the argument is made about Lua deficiency in a 
>way, I view the
>> post as describing problems that are application specific.
>
>Except that I'm not talking about an application, but a 
>library. The idea is 
>that a lot of applications will be created using this library. 

Well, I guess I don't put a lot of weight on the distinction between application and libraries.

>
>Failure to collect reference cycles is a problem 
>associated with 
>specific memory management strategies.

I agree here.

>> Wtih Lua we have the same thing -- Lua references its 
>objects in one way
>> and userdata does (or doesn't) the same in some other way for what is
>> stored inside it. This amounts to two referencing systems 
>for two different
>> kinds of objects that happen to relate with each other in some way.
>
>The trouble is that 'some way' introduces memory management 
>overlaps which are 
>a pain to resolve correctly, and that fact is a consequence of 
>the language 
>design.
>
>> I think, no matter what we do one problem will persist and that is:
>>
>> 	When the last Lua reference to a userdata object is 
>gone there is no
>> guaranty that C object stored in such userdata has no outstanding
>> references on the host app side and vice versa.
>
>Not unless the C code provides a such a guarantee, and it 
>/should/ provide 
>one. The problem is that it is not presently easy to do this 
>in the general 
>case without introducing the possibility of uncollectable 
>reference cycles.
>

This is somewhat not clear to me. We know how Lua deals with its references. In order to solve your issues we have to also impose certain protocol on the application with respect to GC and reference trecking strategy on the host side. Right? Without such protocol/requirement how can one guaranty that host application references are in some sort of synch with Lua side. For instance in my app I also use objects that are made of pairs <userdata(UD), table(T)>. One protocol I use is this 

1. UD is referenced only once on the host side unless referenced by another object in my object universe.
2. UD's GC is triggered by T's GC. T life time implies UD life time, while the other way around is not true. 
3. UD knows its T and vise versa.

The GC for this scheme works well -- cycles or no cycles (because of item #1 and #2). That is, I can reference any Lua objects from any of my <UD, T> objects and everything would get collected in its due time following standard Lua GC protocol. Basically, whatever T holds in it, can also be said as being held by UD (it's fully accessible from UD) . Whenever T is collected with everything it held inside, UD is collected and that is the end of it. This is an application specific protocol that may not suit everyone. I use another protocol for other kinds of objects -- it's also application specific. What scheme do you have in mind that would satisfy everyone? IOW, what protocol with regard to userdata would one have to follow on C side to have everything working the way you envision?

>I was talking more about pooling of live 
>objects such as 
>database handles, where the GC is used to determine when a 
>handle is returned 
>to the pool, but of course that can be done fairly easily by 
>decoupling the 
>Lua-side and C-side handles.
>

Oh, sorry, yeah this is definitely solvable on the app/library side. I thought you wanted to pool Lua userdata objects as these are being deallocated after GC.

>-- Jamie Webb
>
>