Re: [PATCH] make light userdata a little bit heavier

[Ross Bencina <rossb-lists@...>]

On 22/04/2014 7:38 AM, Tom N Harris wrote:
> On Monday, April 21, 2014 07:34:40 PM Ross Bencina wrote:
> > >I just wanted to add my support to your idea. Thanks for the patches. I
> > >think that what you are proposing is a useful idea. If a similar
> > >mechanism was available as part of Lua core I would use it.
> > >
> > >The problem for me with light userdata is that they are typeless (like a
> > >void pointer in C). There is no built-in way for either Lua nor C to
> > >associate a type with the pointer. This becomes a problem as soon as
> > >light user data is used for two distinct purposes in the code.
>
> You can associate an extended type using a weak-keyed table. (But now that I
> remember light userdata doesn't create garbage, the table needs to be manually
> curated to remove dead pointers.) And it only adds overhead for each userdata
> you assign a type to.

Hi Tom,

My use-case involves a large amount of these light userdata, so "only" 
adding overhead to each userdata can also be a problem.

That said, I'm very interested in workarounds and alternatives like your 
suggestion above.


> 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.


> 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.

The question I ask in my C code is: I have this light userdata value, 
does it refer to the type of object that I think it should? or did the 
Lua user pass in some other thing that is also represented by light 
userdata? With Peng's patch I can answer this question with a wost-case 
O(1) tag check, using a tag stored in bits that are already allocated 
and currently unused. Yes, there are other ways to do it, not many are 
this low overhead though.

If adding an extra layer of indirection is an acceptable solution then I 
don't really gain anything, possibly I lose -- maybe this is where 
you're coming from? The saying goes that "all problems in computer 
science can be solved by adding an extra layer of indirection." Just 
because indirection can be used to solve a problem does not mean that it 
should.

Ross.