Re: LuaJIT FFI __gc metamethod?

[Josh Haberman <jhaberman@...>]

Mike Pall <mikelu-1102 <at> mike.de> writes:
> Good news: you can drop your userdata workarounds now -- I just
> added finalizers to cdata objects:

That's great news, but actually for my case I think the userdata might
still be the way to go, because I want users to go through my wrapper
functions that implement certain semantics (like eg. setting "has_foo"
to true whenever "foo" is set).  With a userdata I can implement these
wrappers using __index and __newindex.

Maybe I could hide the actual members instead by giving them obscure
names like __foo and __has_foo, and then use __index and __newindex
on cdata objects to implement my semantics when the user says
obj.foo = 5.  But then I have to trust users not to touch the real
members obj.__foo and obj.__has_foo whereas with a userdata
I can make them mostly inaccessible.

Would the straight cdata approach be noticeably more efficient?

Also, is there a way I haven't thought of to hide the real members of
the cdata from Lua?  I've been wondering if one could sandbox
Lua programs such that they can use modules that are implemented
with FFI, but cannot themselves use FFI or access any FFI data directly.
Is there any reasonable way you could prevent direct access to cdata
in a Lua program, but allow it if the Lua program called into a module
that had FFI enabled?  Does a function have source/line information
about where it was defined that could be used to perform this access
control?

This would let Lua programs be as safe as they ever were (including
the ability to run untrusted programs); only the modules would have
the extra responsibility of not crashing the VM.  You could get
both the efficiency of FFI and the safety of non-FFI Lua.  But maybe
there's no reasonable way to do this.

Thanks for adding cdata finalizers!

Josh