Re: LuaJIT 2 ffi (casting / force hotpath)

[Florian Weimer <fw@...>]

* Mike Pall:

> Florian Weimer wrote:
>> I think it could be useful if you could create a cdata/userdata
>> combination.  This would allow access to the blob in a userdata as a C
>> structure, and you could still provide an object-specific metatable.
>
> The FFI treats userdata like a 'void *' pointing to the payload.
> So you can assign or cast it to a pointer to a struct and then
> access its fields:
>
>   ffi.cdef[[
>   typedef struct { int x; } foo_t;
>   ]]
>   local tostruct = ffi.typeof("foo_t *")
>   local function inc_x(ud)
>     local s = tostruct(ud)
>     s.x = s.x + 1
>   end

Ah, very nice.  You have to check the metatable just as in C, but
making this explicit clearly simplifies the FFI model.

>> I think this is surprising (to a C++ programmer at least):
>>
>> | Objects which are passed as an argument to an external C function
>> | are kept alive until the call returns.
>>
>> I think the lifetime should extend to full expression, that is, beyond
>> the call.  The reason is that a function might return a pointer that
>> is passed in, such as:
>>

> There's no way to do that, since the bytecode doesn't have any
> concept of sequence points. And the FFI knows nothing about the
> bytecode, too.

You could keep all intermediate values alive until you reach the end
of the full expression, but this likely interferes with tail calls and
has performance issues.

> The FFI has a strict 'no hand-holding' policy. If you want to keep
> some object alive, then assign it to a local variable:
>
>   do
>     local a = ffi.new(...)
>     do_something(check_string(a))
>     ...
>   end -- 'a' is not GC'ed before here

I think we have to wait and see if this lack of reliable functional
composition causes trouble in practice.  To be honest, I've seen
obscure problems even with the C++ full expression rule.  So it might
very well be better to be very explicit about guaranteed minimum
lifetimes.

More questions:

Is there a way to mark af FFI calls which may trigger callbacks (via C
extensions)?  What's the general story about callbacks?

Do you plan to make popular POSIX types (off_t, time_t, struct
timeval, struct timespec), constants (those for errno, for instance)
and errno itself available without meddling with header files?  It's
great if you can get this data from header files, but reading them has
downsides (performance, availability at run time, compatibility issues
caused by new GCC extensions).