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
