lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

+1 for this post.

Not everyone can be satisfied, and trying in doing might slow things down.

It seems there is plenty of good stuff in luvit. I for one love the "localized" require, and if the license allows I might borrow it :)

(I've never used node.js, or done much web/http server programming, but might be interresting starting point for me)

On 12/6/2011 9:13 AM, Tim Caswell wrote:
On Tue, Dec 6, 2011 at 10:58 AM, Daniel Aquino
<>  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

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<>  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
<>  wrote:
On Tue, Dec 6, 2011 at 5:34 AM, Axel Kittenberger<>  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.