A garbage collector question

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

A garbage collector question

Marc Balmer
The 5.1 refrence manual says about garbage collecting userdata:

"At the end of each garbage-collection cycle, the finalizers for
userdata are called in reverse order of their creation, among those
collected in that cycle. That is, the first finalizer to be called is
the one associated with the userdata created last in the program. The
userdata itself is freed only in the next garbage-collection cycle. "

But this does not imply that the __gc field is called twice, right?
I.e. the __gc field of any userdata value is called exactly only once,
is that correct?

Thanks,
Marc

Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Thijs Schreijer
Yep. 1st calls gc method, 2nd frees the ud.

Iirc there is an exception with os.exit() that might cause the gc method not being called.

Thijs

Marc Balmer <[hidden email]> schreef:
The 5.1 refrence manual says about garbage collecting userdata:

"At the end of each garbage-collection cycle, the finalizers for
userdata are called in reverse order of their creation, among those
collected in that cycle. That is, the first finalizer to be called is
the one associated with the userdata created last in the program. The
userdata itself is freed only in the next garbage-collection cycle. "

But this does not imply that the __gc field is called twice, right?
I.e. the __gc field of any userdata value is called exactly only once,
is that correct?

Thanks,
Marc

Reply | Threaded
Open this post in threaded view
|

RE: A garbage collector question

Thijs Schreijer
> Sent: maandag 8 oktober 2012 9:27
>
> > Marc Balmer <[hidden email]> schreef:
> > The 5.1 refrence manual says about garbage collecting userdata:
> >
> > "At the end of each garbage-collection cycle, the finalizers for
> > userdata are called in reverse order of their creation, among those
> > collected in that cycle. That is, the first finalizer to be called is
> > the one associated with the userdata created last in the program. The
> > userdata itself is freed only in the next garbage-collection cycle. "
> >
> > But this does not imply that the __gc field is called twice, right?
> > I.e. the __gc field of any userdata value is called exactly only
> once,
> > is that correct?
> >
> > Thanks,
> > Marc
>
> Yep. 1st calls gc method, 2nd frees the ud.
>
> Iirc there is an exception with os.exit() that might cause the gc
> method not being called.
>
> Thijs

Just looked up the os.exit() in the ref manual, and it differs for 5.1 / 5.2

For 5.1:
--------
> os.exit ([code])
> Calls the C function exit, with an optional code, to terminate
> the host program. The default value for code is the success code.

For 5.2:
--------
> os.exit ([code [, close])
> Calls the C function exit to terminate the host program. If code
> is true, the returned status is EXIT_SUCCESS; if code is false,
> the returned status is EXIT_FAILURE; if code is a number, the
> returned status is this number. The default value for code is true.
>
> If the optional second argument close is true, closes the Lua state
> before exiting.

For __gc to run the Lua state must be closed as mentioned with the 5.2 os.exit(). What isn't mentioned is what Lua state is being closed, but I would assume only the current state. Some clarification in the manual would be nice.



Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Marc Balmer
Am 08.10.12 11:21, schrieb Thijs Schreijer:

[...]

> Just looked up the os.exit() in the ref manual, and it differs for 5.1 / 5.2
>
> For 5.1:
> --------
>> os.exit ([code])
>> Calls the C function exit, with an optional code, to terminate
>> the host program. The default value for code is the success code.
>
> For 5.2:
> --------
>> os.exit ([code [, close])
>> Calls the C function exit to terminate the host program. If code
>> is true, the returned status is EXIT_SUCCESS; if code is false,
>> the returned status is EXIT_FAILURE; if code is a number, the
>> returned status is this number. The default value for code is true.
>>
>> If the optional second argument close is true, closes the Lua state
>> before exiting.
>
> For __gc to run the Lua state must be closed as mentioned with the 5.2 os.exit(). What isn't mentioned is what Lua state is being closed, but I would assume only the current state. Some clarification in the manual would be nice.

Thanks for digging this up!



Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Roberto Ierusalimschy
In reply to this post by Thijs Schreijer
> For __gc to run the Lua state must be closed as mentioned with the 5.2
> os.exit(). What isn't mentioned is what Lua state is being closed,
> but I would assume only the current state. Some clarification in the
> manual would be nice.

>From Lua you cannot see more than one Lua state. The entire world is
one Lua state. So, that state is the one that os.exit closes. There is
no other.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Rena

On 2012-10-08 9:26 AM, "Roberto Ierusalimschy" <[hidden email]> wrote:
>
> > For __gc to run the Lua state must be closed as mentioned with the 5.2
> > os.exit(). What isn't mentioned is what Lua state is being closed,
> > but I would assume only the current state. Some clarification in the
> > manual would be nice.
>
> >From Lua you cannot see more than one Lua state. The entire world is
> one Lua state. So, that state is the one that os.exit closes. There is
> no other.
>
> -- Roberto
>

That seems to conflict with the statement that it calls exit and terminates the host program. How do other states survive that?

Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Coda Highland
On Mon, Oct 8, 2012 at 10:12 AM, Rena <[hidden email]> wrote:

> On 2012-10-08 9:26 AM, "Roberto Ierusalimschy" <[hidden email]>
> wrote:
>>
>> > For __gc to run the Lua state must be closed as mentioned with the 5.2
>> > os.exit(). What isn't mentioned is what Lua state is being closed,
>> > but I would assume only the current state. Some clarification in the
>> > manual would be nice.
>>
>> >From Lua you cannot see more than one Lua state. The entire world is
>> one Lua state. So, that state is the one that os.exit closes. There is
>> no other.
>>
>> -- Roberto
>>
>
> That seems to conflict with the statement that it calls exit and terminates
> the host program. How do other states survive that?

Clearly, they don't. They get abruptly terminated, with no final gc sweep run.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Roberto Ierusalimschy
> >> >From Lua you cannot see more than one Lua state. The entire world is
> >> one Lua state. So, that state is the one that os.exit closes. There is
> >> no other.
> >>
> >> -- Roberto
> >>
> >
> > That seems to conflict with the statement that it calls exit and terminates
> > the host program. How do other states survive that?
>
> Clearly, they don't. They get abruptly terminated, with no final gc sweep run.

Exactly. This is a problem of the host program. For Lua, other Lua
states in the host are like other Tcl states in the host.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: A garbage collector question

Thijs Schreijer
> On Behalf Of Roberto Ierusalimschy
> Sent: maandag 8 oktober 2012 19:37
>
> > >> >From Lua you cannot see more than one Lua state. The entire world
> > >> >is
> > >> one Lua state. So, that state is the one that os.exit closes.
> There
> > >> is no other.
> > >>
> > >> -- Roberto
> > >>
> > >
> > > That seems to conflict with the statement that it calls exit and
> > > terminates the host program. How do other states survive that?
> >
> > Clearly, they don't. They get abruptly terminated, with no final gc
> sweep run.
>
> Exactly. This is a problem of the host program. For Lua, other Lua
> states in the host are like other Tcl states in the host.
>
> -- Roberto

Will the host program be able to catch the call to the underlying c function
exit?


Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Philipp Janda
On 08.10.2012 23:31, Thijs Schreijer wrote:
>
> Will the host program be able to catch the call to the underlying c function
> exit?

Sure. Depending on your needs either use the atexit(3) C function or
supply your own os.exit().

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: A garbage collector question

Luiz Henrique de Figueiredo
In reply to this post by Thijs Schreijer
> Will the host program be able to catch the call to the underlying c function
> exit?

The host can always call atexit...