 |
lua-l archive |
|
|
||
|
Chris Marrin wrote: >
No, I mean a full userdata with a pointer to a void*. Then you allocate the memory to pass to your thread and point at it from the userdata. I believe Lua calls this a "boxed pointer" and it has the advantage that you can use Lua to collect it by adding an __gc metamethod to the userdata.
Sorry, my mistake. In my case, that is not worth it, because the buffers are private to the c-side, and it is just as easy to manually delete them when their owner is gc'ed.
A:
Roberto : "We have no intention of allowing userdata addresses to change during GC. Unlike strings, which are an internal data in Lua, the only purpose of userdata is to be used by C code, which prefer that things stay where they are :)" Adrian :I will now happily pass full userdata to a background thread (IOCP on Windows, fyi).
B:
Chris :I'm not sure if Roberto intended what you think you read. If and when Lua gets a compacting garbage collector, a userdata's address would move around just like any other gc object. Maybe that will never happen and maybe they have some clever way to guarantee that userdatas never move. But it seems like a better idea to not rely on this and use your own data.
I read A to mean that userdata never moves, and will code accordingly. It would be nice to have this point clarified in the manual. psconsider - if a userdata can move due to garbage collection, it would have _major_ implications for c routines. There would need to be clear rules on the lifetime of pointers returned from lua_newuserdata() and lua_touserdata(), and which operations may invalidate them. Or, some contract with the gc to say "leave this block alone".
Adrian