Re: userdata and the gc

[Adrian Sietsma <adrian_groups@...>]

Ben Sunshine-Hill wrote:
> The current garbage collector is non-compacting, so no GCed objects
> ever move around. IIRC, the authors have cautioned that this may not
> always be the case, though a lot of current code I've seen relies on
> unmoving userdata.

 In any case, being on the stack wouldn't affect
> this; the stack is just another element of the root set for
> determining reachability for GC.
That may be so, but consider :

int func(Lua_state* L) {
  void* p = lua_newuserdata(L,sizeof(foo));
...
--  we would all hope that p remains valid,
--  even if we trigger a gc here
...
-- save the ud
  lua_pushstring(L,"foo")
  lua_pushvalue(L,-2);
  lua_rawset(L,LUA_REGISTRYINDEX);

-- pop the ud
  lua_pop(L,1)
--  it would be reasonable if p were invalid here : it's off the stack,
--  so one could argue that invalidates the pointer.
  return 0;
}


My specific problem is thread-related - can I pass a (referenced) full 
userdata pointer to another thread for background i/o, trusting that Lua 
will _never_ delete (or move) the memory pointed to, as long as the ud stays 
referenced ?


If that is the case, I'm confused about how the gc can shrink the pool 
without invalidating userdata. Using sockets for userdata :

require"socket"
s1=socket.tcp() -- create userdata before table
t={}; for i =1,1e6 do t[i]=i end
s2=socket.tcp() -- create userdata after table
collectgarbage("collect");print (collectgarbage("count"))
=>16447.016601563
t={}
collectgarbage("collect");print (collectgarbage("count"))
=> 63.0166015625

so the memory comes back, as confirmed by task manager.
???

Adrian