Re: [ANN] Luvit - Lua + UV + Jit = NodeJS re-implemented in Lua

[Daniel Aquino <mr.danielaquino@...>]

You can look at how Twisted does it if you want.

I was just making the point that stealing the main loop away might not
work for everyone or integrate with other projects who made the same
choice.


On Tue, Dec 6, 2011 at 11:20 AM, Tim Caswell <tim@creationix.com> wrote:
> I have no interest in messing with select, epoll, kqueue, IOCP, or any
> of the other kernel level event loops that vary wildly between
> platforms.  I trust libuv to handle that for me and it's outside the
> scope of my project.
>
> As far as mixing with other event loops, I don't know how to sanely do
> that in a cross-platform way.  I've seen glib and libev work together
> in a few systems I've worked on, but something more general is much,
> much harder.
>
> As far as interfacing with blocking C libraries (like database
> clients) libuv has a thread-pool made just for this. It's used
> internally for filesystem operations since there are very few truly
> async filesystems in the world.  It also exposes a generic API for
> wrapping blocking calls and putting them in the thread pool.  This is
> not a good solution for anything network related. Threads are very
> expensive, especially the locking.
>
> As far as node and SDL, that was pretty easy.  I just set up a 60hz
> interval in javascript and polled SDL's event queue.  SDL is nice that
> it can have it's own loop of be polled from another.  The 60hz polling
> is fine for SDL since it's normally used for single client games or
> applications and the animation and physics engine is already probably
> polling at 60hz.  To do the same from luvit I would do the same. I
> would set up a 60hz repeating timer and poll SDL (probably via ffi).
> The FFI calls are very fast to SDL and as long as I'm not doing
> anything too expensive, the event loop will stay running quite smooth.
>
> And yes, luvit supports co-routines on all async function callbacks if
> you prefer that style.
>
> -Tim Caswell
>
> On Tue, Dec 6, 2011 at 8:34 AM, Javier Guerra Giraldez
> <javier@guerrag.com> wrote:
>> On Tue, Dec 6, 2011 at 5:34 AM, Axel Kittenberger <axkibe@gmail.com> wrote:
>>> There's no magic bullet to everything work together with everything.
>>> Maybe you could make some common API so you can plug in different
>>> reactors to handle that select()ish thing. But I don't see how getting
>>> all agree to that common API you suggest is better than to just all
>>> agree to the API of one event reactor. In case of using SDL Tim can
>>> sure shine some light on it, actually the same author as luvit did
>>> node-sdl, the SDL interface for node.
>>
>> that's exactly what i found some time ago: not all interesting APIs
>> can give you a filedescriptor with the promise "mind your business,
>> i'll signal on this descriptor when something happens" like I/O does.
>>
>> the only generic solution that i could imagine was making it (almost)
>> trivial to write helper threads: delegate all blocking calls to a
>> thread whose only job is to wait (blocked) until the call returns,
>> then signal to the main event loop.  the result is (obviously) my HTT
>> package, which includes a simple (but fast!) coroutine-based scheduler
>> so that the Lua side is easy to write too.
>>
>> TL;DR: if the APIs are event-friendly, Lua makes it delightully easy
>> to write event-based code, by means of coroutines.  if the APIs are
>> strictly blocking, a slim C/threads adaptor is needed.
>>
>> --
>> Javier
>>
>