RE: userdata and garbage collection in lua 5.0

[Asko Kauppi <Asko.Kauppi@...>]

At least to me, your reasoning sounds ...well... reasonable :).

I've been trying to figure out the new userdata model and there seems to be
very few samples around (the one you mentioned was the only one I found).
Perhaps the 'FILE*' case is the most common way userdata would be used
anyways (to store a handle to externally opened/closed resources).

So I vote YES - what about the authors?

Yours, - ak


> -----Original Message-----
> From:	Benoit Germain [SMTP:bgermain@ubisoft.fr]
> Sent:	Thursday, August 22, 2002 5:47 PM
> To:	Multiple recipients of list
> Subject:	userdata and garbage collection in lua 5.0
> 
> Hello List,
> 
> I was looking at liolib.c to see how userdata is used in real life, and
> observed this:
> lioblib exposes a userdata to lua that holds a FILE*. To do so it actually
> creates a userdata that points to a pointer, this pointer being the FILE*.
> This is necessary because the FILE structure whose FILE* we have is
> obtained
> through an external allocation scheme with fopen(), therefore lua cannot
> simply create a userdata containing a FILE structure (it is not exposed
> anyway), then ask some C call to fill it accordingly. Thus, upon garbage
> collection of the userdata, the __gc metamethod is called to close the
> file
> (which actually does fclose(FILE*) thus freeing the structure), then the
> memory block is garbage collected.
> 
> I was wondering if it could not be possible in this particular case, to
> remove the need for this lonely intermediate pointer ?
> This could be done through a return value of the metamethod, that, if
> non-nil/false, tells the gc if actual collection of its memory area is
> necessary.
> To enable this, one would only have to be able to tell lua, when creating
> a
> userdata, if this memory block is needed, or if it can use the provided
> pointer as is.
> 
> For example, liolib uses the lua_boxpointer macro which creates a new
> userdata (with lua_newuserdata) that contains a single pointer, and stores
> the FILE* in it. the current prototype of lua_newuserdata(L,size) does not
> allow for what I am thinking about, but what if it was changed to
> lua_newuserdata(L,p,size) ?
> When p is NULL and size is not, lua creates the memory block as before.
> When
> p is non-NULL and size is 0, lua stores p directly in the userdata. If
> both
> are 0 or non-0, an assertion is raised.
> In the first case, the implementor must have its __gc metamethod return
> true, and in the second case it must return false.
> 
> I don't know if I am too clear about this, so feel free to tell me what's
> wrong about my reasoning :-)
> 
> Cheers,
> 
> Benoit.
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.