[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: userdata and garbage collection in lua 5.0
- From: Asko Kauppi <Asko.Kauppi@...>
- Date: Fri, 23 Aug 2002 10:01:16 +0300
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:firstname.lastname@example.org]
> 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
> 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
> (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
> To enable this, one would only have to be able to tell lua, when creating
> 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.
> p is non-NULL and size is 0, lua stores p directly in the userdata. If
> 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 :-)
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.