Am 22.04.2014 08:11 schröbte Ross Bencina:
As I understand it, there were two separate patches. One patch added an
extra field, the other patch made use of spare bits in the existing
structure.
The latter used spare bits only, but you can have only 4 (5?) different
types of lightuserdata in total. As soon as 5 or more people decide to
use this feature for their lightuserdatas you are right back where you
started, so this mechanism can only be useful in isolated environments.
The former patch _did_ add an extra field to every Lua value, but unless
I miss something you could just as well reuse the existing tag field
(only a dozen or so values are used at the moment). The downside (aside
from a few extra fields in the main Lua state) is that you can't use the
NaN trick any more, but in Lua 5.3 or on 64-bit architectures that
wouldn't work anyway. (On 64-bit architectures you would even have room
for another 4-byte value because of padding.)
So, IMHO, the first patch makes no sense in Lua 5.3 and/or on amd64,
because it is very limited for no good reason.
I don't see what you gain from doing this.
What I gain is the ability to verify the type safety of light userdata
usage on the C side, and/or the ability to discriminate types of light
userdata. This is useful for making a binding to C code that is both
efficient and that won't crash when I pass a ref of type A to a function
that expects a B.
But it still will crash (hopefully) if you pass a lightuserdata to a
freed object. There is *no* automatic resource management when using
lightuserdata as a poor-man's reference type instead of a value type
(i.e. you use the pointed-to value not just the pointer value), so you
are back to manual memory management and segmentation faults like in C
(with a more pleasant syntax I admit).
