 |
lua-l archive |
|
|
||
|
Am 22.04.2014 08:11 schröbte Ross Bencina:
On 22/04/2014 7:38 AM, Tom N Harris wrote:The patch costs an extra field in every value, not just userdata.I agree that adding a field to every value may not be desirable. 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).
Ross.
Philipp