Re: Announcing moonslice luv*, and lhttp_parser

[Coda Highland <chighland@...>]

On Wed, Oct 10, 2012 at 2:14 PM, Tim Caswell <tim@creationix.com> wrote:
> On Wed, Oct 10, 2012 at 4:06 PM, Coda Highland <chighland@gmail.com> wrote:
>> On Wed, Oct 10, 2012 at 1:57 PM, Richard Hundt <richardhundt@gmail.com> wrote:
>>> However, ØMQ aside, why does the presence of a coroutine scheduler on top contribute to it being "more than just libuv bindings"?
>>
>> Read that as "more than just a bare-bones wrapper around libuv" and it
>> may make more sense to you. Yes, it's a set of bindings to libuv, but
>> it's a high-level binding, not a low-level one.
>
> In my opinion, C bindings should only do what you can't do in lua.
> Especially highly debated topics like async API style.  Adding
> coro-sugar on top can be done in pure lua.  If I do the bindings
> right, than Richard should be able to put my library inside his if he
> so chose.
>
> Also, I've found that in JIT engines, the more logic you push to lua,
> the more it can optimize.  I know this is very true for V8 and
> JavaScript.  I expect the same to be true to some extent for luajit.

This is very true for LuaJIT; Mike has said so a number of times on
the LuaJIT mailing list: the JIT can't do much optimization if you're
calling functions implemented using the Lua C API, and it's usually
more efficient to implement generic callback-based algorithms entirely
in Lua instead of writing the function in C and invoking a Lua
callback inside that.

There IS a major caveat to be noted, though, that is highly relevant
to this discussion: LuaJIT has (1) a limited number of callback slots
available, (2) can't optimize calls from C to Lua (e.g. for a
callback-based architecture).

What this means in practice is that you probably want some sort of
Lua-side dispatcher so you can minimize the number of callbacks passed
to C functions in order to avoid exhausting those slots and do more
work Lua side, but even so there are some nuances that I personally am
not fully familiar with.

Of course, LuaJIT has one even bigger catch you want to observe: You
should almost certainly use the FFI instead of Lua C API bindings,
because the JIT *can* optimize across FFI calls. This probably means
having separate Lua and LuaJIT versions of luv that expose the same
API but use the FFI where available.

/s/ Adam