the following code should return immediately but it doesn't:
r = uv_timer_init(uv_default_loop(), &once);
r = uv_timer_init(uv_default_loop(), &never);
r = uv_timer_start(&never, never_cb, 86400 * 1000, 0);
r = uv_timer_start(&once, once_null_cb, 0, 0);
r = uv_run_once(uv_default_loop());
the loop calls once_null_cb() immediately but then waits for the next timer.
the same thing happens if the timer is small enough. e.g. <5ms
use async_t if you want to emulate NO_WAIT.
How? I'd like to implement something like uv_run_once(loop, max_wait_time).
You may want to check this out: #561
Thanks. I'll wait for that API to be implemented on all the platforms.
Currently I'm sending a async event in the timer callback to make sure the loop will be wake up, but that is a side effect.
@rogerwang We will have this, some day :-)
You cal also prevent the loop from blocking by starting an uv_idle handle with a dummy callback. That should be more efficient than using an uv_async handle.
I can confirm the bug. It works when you close the zero timeout handle in its callback but if you leave it open (open but inactive), the event loop stalls.
Just want to comment that runloop integration is something I've tackled a few times for Plask. I've just recently rewritten it for libuv and taken a new approach (that is kqueue specific). There are at least some helpful comments that explain the approach and might be helpful:
Fixed in 0017c55.
ho! stop! not in v0.10!
It won't work in v0.10 because ffe2ef0 is only in master and can't be landed in v0.10.
Belay that, landed in master only in commit f6d8ba3.
People who really rely on this bug fixed in v0.10 should float ffe2ef0 and f6d8ba3. We can't do that because it changes the ABI.