[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: gc confusion: a solution ?
- From: Juergen Fuhrmann <fuhrmann@...>
- Date: Thu, 20 Feb 2003 11:44:49 +0100 (MET)
> Wed, 19 Feb 2003 15:48:58 +0100 (MET)
> Juergen Fuhrmann <firstname.lastname@example.org> wrote:
> > Wed, 19 Feb 2003 11:27:44 -0300
> > Roberto Ierusalimschy <email@example.com> wrote:
> > > When userdata is garbage collected if I call Lua from C ? I call it
> > > this way: [...]
> > When you do
> > lua_pushusertag(L,my,my_tag);
> > you may create a new userdata, or not, if there is one like it already.
> > (This is one of the reasons we change this in Lua 5.0. In 4.0 there
> > is no way to know when you actually create a new userdata.) If you
> > are creating a new userdata (that i,s "my" is a new address), then
> > this stack entry is its only reference. Once myPrint returns, there is
> > no reference left to this new userdata, so it should be collected in
> > the next GC cycle. (It may be collected even before that, if myPrint
> > modifies this argument and there is a GC cycle.)
> Ok. This means that it needs to be garbage collected if there is no
> reference. I force a GC cycle just after the call, so the linux
> behaviour is right.
So I am learning now the gc issue "the hard way". I found a solution
for the problem that userdata in callback might be known in Lua
previously or not. If it works, it would be fine for me (but not for
those with limited gc time frame).
I anyway implemented my own refcounting and bound the release methods
to the gc tag methods. So in my callback, after finishing my job, I
force a gc cycle (ok for me, but perhaps not for everyone). After that
I can see at the refcount if the gc had bitten me or not. So I define
#define lua_protect(obj,count) (addref(obj),count=obj->refcount)
#define lua_unprotect(obj,count) (obj->refcount==count?release(obj):0)
and lua_protect/lua_unprotect every userdata object when it is passed
> But why on 64 bit, the behaviour is different ?
The stuff now works well on 32bit, on 64 bit memory keeps growing...