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

[Tim Caswell <tim@...>]

On Tue, Dec 6, 2011 at 10:58 AM, Daniel Aquino
<mr.danielaquino@gmail.com> wrote:
> 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.
>


Thanks you Daniel, I understand that by embedding the event loop
inside luvit and making it implicit makes luvit very hard to integrate
with anything else that has an event loop.  At the same time it makes
it really nice for pure-lua scripts to talk to each other because they
can assume the loop is there and all luvit scripts and modules can use
the same interface.  It's a conscious trade-off I'm making.  I'm also
aware that luvit scripts, while being lua, aren't going to interface
out of the box with most existing lua scripts.  This is part by design
to keep libraries with blocking I/O out of luvit's ecosystem and part
a simple side-effect of my preferred semantics on how require and I/O
should work.

I'm not trying to make this work for everyone.  I'm trying to make it
work for me and my needs and sharing it with the community in case
someone else finds it useful.  Designing for *everyone* has the
unfortunate side effect that nobody is truly happy with it because
people are diverse and have different needs.  If I design for what I
need and it's perfect for me, then it will be great for others too.
This is a well understood principle that good UX designers know and a
large reason that Steve Jobs was able to make Apple so successful.  I
don't condone the closed nature of the Apple ecosystem, I love open
technology, but the idea of a focussed vision is very important.

>
> 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
>>>
>>
>