uv_run_once() should return immediately on a timer with zero timeout #574

Closed
rogerwang opened this Issue Oct 4, 2012 · 13 comments

Projects

None yet

6 participants

@rogerwang

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.

@rogerwang

the same thing happens if the timer is small enough. e.g. <5ms

@txdv

use async_t if you want to emulate NO_WAIT.

@rogerwang

How? I'd like to implement something like uv_run_once(loop, max_wait_time).

@saghul
Joyent member

You may want to check this out: #561

@rogerwang

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.

@piscisaureus
Joyent member

@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.

@bnoordhuis

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.

@deanm

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:

deanm/plask@3db9c66

@bnoordhuis

Fixed in 0017c55.

@bnoordhuis bnoordhuis closed this May 29, 2013
@piscisaureus
Joyent member

ho! stop! not in v0.10!

@piscisaureus
Joyent member

It won't work in v0.10 because ffe2ef0 is only in master and can't be landed in v0.10.

@bnoordhuis

Belay that, landed in master only in commit f6d8ba3.

@piscisaureus
Joyent member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment