Threads Accessing User userdata

[parallax7d]

Why do threads only have shared access to Love userdata, opposed to any other userdata? Is there some sort of private club for Love userdata pointers or something?

[slime]

LOVE's internal code knows what to do to convert a C++ LOVE [wiki]Object[/wiki] to Lua (e.g. creating a wrapper struct and setting up the metatable if needed) and vice versa (getting the C++ object's pointer and type out of the userdata pointer) - but it doesn't know how to do that for "foreign" userdata, since the only place that knows how to turn a C pointer into a Lua userdata object and vice-versa is the code inside the module responsible for it (luasocket, lua-enet, etc).

[parallax7d]

Is Love doing something special to share the region of memory Love types live in among the different thread environments?

[raidho36]

Not really, no. But it has to know the type of object to plant it into a different Lua state (i.e. transport over channel), and it only has that information for its own types. Every foreign type is being completely opaque to it and, while technically being possible to transport, it can not be assigned meaningful type on the receiving end thus remaining an opaque userdata, rendering such operation pointless. You can transport light userdata with no issue, though, since it's an opaque pointer to start with and "reducing" it to opaque pointer doesn't change anything.

[parallax7d]

Would it not make sense to let the user decide if it's pointless? What does Love really need to know? Could it not just call it an 'unknown' type and leave it up to the user to code whatever operations they want it to support? The ability to access our own userdata from more than just the main thread could be useful.

[raidho36]

Assigning type really means here assigning a metatable with native functions, which the framework has no access to. An opaque userdata doesn't have any methods defined on it, and so you can't do anything meaningful with it. In this state it has even less use than light userdata, which points to a valid unencumbered region of memory space, and which you should then use instead anyway.