 |
lua-l archive |
|
|
||
|
On Sun, Jul 17, 2011 at 8:32 AM, Gaspard Bucher <gaspard@teti.ch> wrote:i've been there quite a few times; in short, apart from
> I do not think I could use your suggestion of a centralized event loop. What
> happens with zmq requests for example ? These are synchronous calls that
> cannot easily be "posted" as events. I will investigate further to see how I
> could integrate things like "mdns", "zmq" and Qt in a single event loop: a
> single "select" without mutex seems like the obvious choice but I'm not sure
> I can force ZeroConf and ZeroMQ into Qt slavery.
number-crunching style (where you want to saturate all CPU cores
available), the best is to have a single event loop, and dispatch from
there. on top of this, it's easy to use coroutines to make each
event-driven task seem like it's own loop, if that's what you like.
but the first hurdle, and in many cases the only big one, is how to
make all possible events notify a single loop? the Unix philosophy
would be "everything is a file, so just do select() on all the
channels". unfortunately, at a slightly higher level, very few APIs
look like files. I think zmq has a poll() that takes either zmq
channels or regular files; but other event sources aren't so easy.
so, i think the best solution involves to write some kind of
'adaptors' that take a single source of events and turns into your
main one.
that's what i did on my Helper Threads Toolkit (HTT,
http://github.com/javierguerragiraldez/helper-threads). It keeps a
number of threads running simple C functions, and keeps all
coordinating in Lua. You could use it to write (in C) some simple
code to wait on your event sources and signal to the main code. it
also includes a Copas-like coroutine scheduler.
--
Javier