Re: Inverted _gc

["Deneb aka Alpha Cygnus" <alpha_cygnus@...>]

----- Original Message -----
From: <RLake@oxfam.org.pe>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Friday, July 11, 2003 2:40 AM
Subject: Re: Inverted _gc


> If I'm not mistaken, there has been quite a lot of discussion of this
> issue lately.

Yes, sorry, this IS a double post. I had to check the recent mail before
sending my question. I took the wrong assumption that if it hasn't been
raised before it has low possibility be raised in the recent mail. Well,
that possibility took place. I hate Probability Theory. ;)
>
> My favorite solution: Keep a table in the registry keyed by the address of
> the Delphi object, whose values are the heavy-user data. You can use this
> table to ensure that there is only a single Lua reference to each Delphi
> object. When you delete the object in Delphi, set a flag in the relevant
> userdata, using the address of the Delphi object to lookup the Lua object
> in the registry table [1] or alternatively, set the userdata's contents to
> NULL. This does not cause the Lua object to become nil, but it makes it
> possible for Lua to check the object for validity. Once you have flagged
> the userdata, *remove the key from the registry table*. (This is
> important, both to allow the Lua userdata to be garbage collected, and
> because the object's address may be assigned to a new object.)

Well, I think this will be the solution. All I need, really, is to know if
the pointer I get from Lua in callback is valid. If I try to check it in
Delphi I can get a nasty exception, since it'll try to dereference that
pointer a couple of times to find out the class of the object and its VMT.

>
> The userdata will have a metatable; you can use this to identify the
> object's class. This is handy because it allows you to check the class of
> an object from C as well, simply by looking the address of the object up
> in the registry table and then getting the metatable out of the resulting
> userdata. So you get a form of run-time inspection without having to
> modify the C definition of the object.

I don't need to do some special actions to indetify the class of the object.
The Object Pascal already has built in capabitities for that. Its a part of
RunTime Type Information concept.

>
> You still have a problem if there is some mechanism by which objects can
> be deleted from the Delphi environment without you being informed of that;
> this might be the issue for an object which has a non-Lua garbage
> collection method, such as reference counting. That is more difficult to
> solve; garbage collection methodologies don't easily co-operate with each
> other. Hopefully if this is the case, the C-side memory management system
> will also provide you with a finalisation method.

In fact detecting when the object is deleted in Delphi is also a problem.One
possible way is to recompile the source code for VCL, adding some extra
callback code into TComponent.Destroy. I must think of a better way to do it
:)

Well, to clear up the situation I should say that I am talking of the GUI
(VCL) objects, that are decendants of TComponent class and can be organaized
in hierarchies of ownership. When the owner (e.g. a form) is closed it frees
all the components contained therein. This is the moment I am thinking
about - I want to be able to freely remember components of interest to me in
Lua variables and to safely track references to them from Lua if they do not
exist anymore.