gc confusion: a solution ?

[Juergen Fuhrmann <fuhrmann@...>]

>  Wed, 19 Feb 2003 15:48:58 +0100 (MET)
>  Juergen Fuhrmann <fuhrmann@wias-berlin.de> wrote:
>
>  
>  >  Wed, 19 Feb 2003 11:27:44 -0300
>  >  Roberto Ierusalimschy <roberto@inf.puc-rio.br> 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. 

Hi, 

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
to lua.

>  But why on 64 bit, the behaviour is different ?

The stuff now works well on 32bit, on 64 bit memory keeps growing...

Juergen