[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Feature request: more integration of Lua and C memory management
- From: "Bilyk, Alex" <ABilyk@...>
- Date: Wed, 9 Jun 2004 17:39:54 -0700
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. Clearly the problems descripbed will emerge in any application that aggregates objects. If I have two C++ objects A and B that reference each other and both of them are refcounted I have the same sort of problem. Such problems don't belong to programming langage domain in my view (although .NET does something in this department but only via modifications to C++ language). 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. 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.
The idea of using an array of objects associated with user data can be implemented via a table. Just create a vector table, get a reference to it and store that reference in userdata. On userdata GC you would either release this table's reference or clean it up if there is a need to pool such tables for reuse.
Pooling userdata is a problem that has no clean solution in the existing Lua implementation. This could pbobably be fixed by allowing a special userdata allocator routines to be defined by the host application or just making existing allocation routines take another parameter describing the type of a Lua object being allocated, so that custom memory managers can take a note of it and use pooling when needed. A fixed size custom allocator is another way to solve this problem. The latter in effect would pool everything allocated by Lua (ala STL in C++), being 10x faster while a bit more wasteful as a side effect.
>From: Mike Pall [mailto:firstname.lastname@example.org]
>Sent: Wednesday, June 09, 2004 2:26 PM
>To: Lua list
>Subject: Re: Feature request: more integration of Lua and C memory
>Alex Bilyk wrote:
>> [...] what is more abstract than <void*, size_t> pair?
>The issue is not about representation. The issue is about ownership,
>referentiality and management.
>Jamie gave some good examples in his first posting in this thread: