[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Calling lua functions from C when using luajit ffi.
- From: Tim Caswell <tim@...>
- Date: Mon, 14 Nov 2011 16:59:49 -0600
very cool, if this gets ported to modern arm as well, I might switch
to pure ffi for my project!
On Mon, Nov 14, 2011 at 1:14 PM, Dimiter 'malkia' Stanev
> Mike just put support for callbacks for x86/x64
> I haven't tested it yet, but the docs are updated on how to use it.
> Awesome stuff, and thanks Mike!
> On 10/31/2011 11:54 AM, Tim Caswell wrote:
>> I know this was asked earlier this year, but it doesn't seem to have
>> gone anywhere. The last thing I can find from Mike is:
>>> Callbacks are pretty high on my TODO list for the FFI. But I don't
>>> know when I'll get around to it. The sponsored work has priority.
>> Since I can't find anything about this feature being announced or
>> documented, I'm going to assume the sponsored work is still keeping
>> things busy. (The arm port is very useful btw)
>> I'm wondering if anyone has any ideas for how I could work around
>> this. My program is luvit<https://github.com/creationix/luvit> and
>> I'm wrapping a couple C libraries that are heavily callback based.
>> One is an http_parser which is a sax style parser that calls my
>> "events" as it finds them synchronously. This is simple because the
>> callbacks are called from the same stack that originated in lua. I
>> can assume that once I get a handle to L (my lua_State*) that my
>> userdata is as position 1.
>> My other case is libuv which is a non-blocking I/O library. By
>> definition of it's task, the callbacks get called by C level events
>> and don't originate from any lua call. Currently in my C bindings I
>> store access to L and a lua_ref of my lua callback in the pointer that
>> my C callback has access to. I then unpack everything and call the
>> lua callback from the main thread (to make it co-routine safe).
>> I have both of these cases working as manual C bindings, but I'd
>> really like to try out FFI and see if it's any faster. Perhaps it
>> won't be because my loops cross stacks and all context is lost.
>> -Tim Caswell