On 08/01/2014 07:44 AM, William Ehlhardt wrote: > uv_run getting stuck forever even with UV_RUN_ONCE still seems like a > bug, though. >
It's not. The reason is buried inside how uv_run works, which I need to document for once :-S Basically, you are scheduling a timer for 0ms, which means it's due *now*. Then, when you call uv_run, the first thing to do is run the due timers, so, your timer's callback will be called. Then, the poll timeout will be calculated. If you have that timer and a TCP server, for example, the polling timeout would infinite, because your timer is not active (I assume you didn't set repeat), so it doesn't count nor there is any other condition to make the timeout be 0. The loop will block for i/o for the aforementioned amount of time. It will return when there is some i/o activity. i/o callbacks will be fired, also check and close. Then uv_run will return. UV_RUN_ONCE doesn't imply not blocking waiting for i/o, that's what UV_RUN_NOWAIT does. Hope that clears it up a bit. Cheers, -- Saúl Ibarra Corretgé bettercallsaghul.com
signature.asc
Description: OpenPGP digital signature
