I've read #1565 but I don't understand why this is necessary.

loop->watcher_queue are the file descriptors to add before the next call to epoll_wait() or kevent().

Why should uv_backend_timeout() return 0 when file descriptors are added? It seems unrelated.

When new file descriptors will be added you need to call uv_run again without blocking. Otherwise you can't get notified of new events (through uv_backend_fd). For example, consider the following main loop:

while (is_running) {
    uv_run(loop, UV_RUN_NOWAIT);
    int timeout = uv_backend_timeout(loop);
    // Run main event loop with timeout as max timeout.
}

Consider what happens if you call uv_read_start() from within a uv callback. Now you really need to call uv_run() again immediately (hence why you should return 0 from uv_backend_timeout).

Sorry for the delay, the notification got buried in my inbox.

Okay, I see what you mean now but this change as it stands would busy-loop on Solaris/Illumos because of these three lines.

I don't care much about that platform but if we ever added a select(2) back-end, it would probably have the same issue, so I think we need to address this.

What might work is to claim a bit in uv_loop_t.flags and set it in uv__io_start() and uv__io_stop() when a watcher is inserted into loop->watcher_queue. If the bit is set, uv_backend_timeout() returns zero.

It's not completely watertight because all watchers might get stopped again before uv_backend_timeout() is called. In that case the bit should be cleared again but it might be difficult to implement that without also implementing some kind of reference counting.

This PR hasn't seen action in almost two years so I'll take the liberty of closing it out.