Use alignment hack to workaround luajit lightuserdata

[daurnimator]

Idea from #241 (comment)

@vcunat please review?

[vcunat]

🤔 cqueues seem to be using that mask on various static const int (defined inside functions), and there I don't see any guarantee that they will be placed at least 32 bytes apart.

I also don't know if the mentioned "negative pointers" are realistic; they would cause problems

0xFFF0000000000000 to 0xFFFFFFFFFFFFFFFF

– not just for uniqueness but they would still be over 47 bits in the code as written ATM.

[daurnimator]

thinking cqueues seem to be using that mask on various static const int (defined inside functions), and there I don't see any guarantee that they will be placed at least 32 bytes apart.

Ah yep... I wonder if results from lua_newuserdata are guaranteed to fit in a lightuserdata. But looks like we'll need to different methods.

I also don't know if the mentioned "negative pointers" are realistic; they would cause problems

0xFFF0000000000000 to 0xFFFFFFFFFFFFFFFF

– not just for uniqueness but they would still be over 47 bits in the code as written ATM.

ah right; we still need the mask.

Another thought: we should mix the high bits into the low bits to preserve uniqueness if we use multiple methods.

[vcunat]

Uniqueness: if you shift by six bits and use a 47-bit mask, you'll get the "sign" bit in the most significant one. EDIT: so possibilities are there, but the overall space to cover might be a bit large.

[daurnimator]

re: uniqueness I was thinking of if you ended up with e.g.

0x0000001234567800 as cqueue__poll (imagining we shifted by 8)
and
0x0000000012345678 as something returned from lua_newuserdata

then they could collide.
so instead of shifting 0x0000001234567800 right by 8; we'd move the high bits to low: x | ((x & 52) >> (52 - 8)) or something

[vcunat]

I didn't realize you want to avoid collisions with other values, too.

[vcunat]

So... we give this up in favor of LuaJIT/LuaJIT@e9af1abec54 ?

[daurnimator]

So... we give this up in favor of LuaJIT/LuaJIT@e9af1ab ?

ooo, yeah that sounds like a reasonable idea.... does it all work well?

[vcunat]

I haven't tried it yet, but on a quick look, the approach supports up to 256 37-bit segments, so that sounds like a nice compromise.

[daurnimator]

Closing as LuaJIT/LuaJIT@e9af1abec54 is the real fix.

We should remove the current 47bit hack code in the next release.