When will userdate be freed/gced?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

When will userdate be freed/gced?

Marc Balmer
In a C  function that is called from Lua, I use the following idiom:

char *s;

...

s = lua_newuserdata(L, 128);

...

return;

After this function returns, what happens to the userdata?  Will it be garbage collected eventually or do I have to free() the pointer returned by lua_newuserdata()?  How does Lua "know" when the userdata is no longer used?


Reply | Threaded
Open this post in threaded view
|

Re: When will userdate be freed/gced?

Andrew Gierth
>>>>> "Marc" == Marc Balmer <[hidden email]> writes:

 Marc> In a C  function that is called from Lua, I use the following idiom:
 Marc> char *s;
 Marc> ...
 Marc> s = lua_newuserdata(L, 128);

Notice that this pushes the Lua value onto the stack, in addition to
returning a pointer to the data block address.

While the value is on the Lua stack, it is referenced and therefore will
not be GC'd. If you drop it from the stack without storing some other
reference to the value (e.g. by putting it in a table, closure, or
uservalue), then it will be GC'd when the collector next gets around to
it. If you did store it somewhere, then it will not be GC'd until after
all such (strong) references no longer exist or are no longer reachable.

You should never try and free it explicitly.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: When will userdate be freed/gced?

Marc Balmer


> Am 07.04.2019 um 14:07 schrieb Andrew Gierth <[hidden email]>:
>
>>>>>> "Marc" == Marc Balmer <[hidden email]> writes:
>
> Marc> In a C  function that is called from Lua, I use the following idiom:
> Marc> char *s;
> Marc> ...
> Marc> s = lua_newuserdata(L, 128);
>
> Notice that this pushes the Lua value onto the stack, in addition to
> returning a pointer to the data block address.
>
> While the value is on the Lua stack, it is referenced and therefore will
> not be GC'd. If you drop it from the stack without storing some other
> reference to the value (e.g. by putting it in a table, closure, or
> uservalue), then it will be GC'd when the collector next gets around to
> it. If you did store it somewhere, then it will not be GC'd until after
> all such (strong) references no longer exist or are no longer reachable.
>
> You should never try and free it explicitly.

Of, so if I understand correctly, if I just call lua_newuserdata and use the memory pointed to it internally in my function, it will get GCed (I am not storing a reference anywhere).



Reply | Threaded
Open this post in threaded view
|

Re: When will userdate be freed/gced?

Andrew Gierth
>>>>> "Marc" == Marc Balmer <[hidden email]> writes:

 >> Notice that this pushes the Lua value onto the stack, in addition to
 >> returning a pointer to the data block address.
 >>
 >> While the value is on the Lua stack, it is referenced and therefore will
 >> not be GC'd. If you drop it from the stack without storing some other
 >> reference to the value (e.g. by putting it in a table, closure, or
 >> uservalue), then it will be GC'd when the collector next gets around to
 >> it. If you did store it somewhere, then it will not be GC'd until after
 >> all such (strong) references no longer exist or are no longer reachable.
 >>
 >> You should never try and free it explicitly.

 Marc> Of, so if I understand correctly, if I just call lua_newuserdata
 Marc> and use the memory pointed to it internally in my function, it
 Marc> will get GCed (I am not storing a reference anywhere).

You need to be aware of when exactly you're dropping the value off the
Lua stack, because as soon as you do that, the next API call that
allocates memory could invoke the GC and free your userdata.

--
Andrew.