On Thu, Jan 22, 2015 at 8:27 PM, Fredrik O <
evo...@gmail.com> wrote:
> Sorry Matt, I was not precise enough. It was only an example. The reality is
> that I am building a new sort of platform above node and was curious if
> there is something I can invoke to force the event loop immediately to be
> processed.
>
> I found UV_RUN_NOWAIT but it seems not to fire any http listeners (when a
> new connection is received). C++ code:
>
> // Within a C++/v8 addon
> int r = uv_run(uv_default_loop(), UV_RUN_NOWAIT);
>
> I modified the library uvrun to use the option UV_RUN_NOWAIT, but it does
> not work properly. It does not fire any callbacks even if I call it within a
> while-loop. Any clue why? Or who I may ask?
The event loop is not re-entrant. Calling uv_run() from a callback
that itself originates from a call to uv_run() is undefined behavior,
there are no guarantees about what will happen.
Barring bugs, it should work when called from the top-level script.
However, many things inside core use process.nextTick() and that
function is pretty much an event loop in its own right, one that is
separate from the libuv event loop.
The precise semantics are convoluted but process.nextTick 'ticks'
happens around calls from C++ into JS land. If there are no such
calls, no tick callbacks run. Calls frequently originate from libuv
callbacks but:
1. If the libuv event loop is not making forward progress because it's
waiting for tick callbacks, and
2. If those tick callbacks are not happening because of a lack of C++
-> JS calls, then
3. Everything stalls!
To make a long story short, when you start meddling with the event
loop, it's just too easy to create a catch-22 situation. Hope that
helps!