accept4() piggybacks on the socketcall() on i386. socketcall() has the flaw
that it returns EINVAL instead of ENOSYS when the operation is not supported.
The problem is that accept4() also returns EINVAL when its flag argument is
invalid.
Try to discern between the two failure cases to the best of our abilities.
This commit changes how the event loop determines if it needs to stay alive.
Previously, an internal counter was increased whenever a handle got created
and decreased again when the handle was closed.
While conceptually simple, it turned out hard to work with: you often want
to keep the event loop alive only if the handle is actually doing something.
Stopped or inactive handles were a frequent source of hanging event loops.
That's why this commit changes the reference counting scheme to a model where
a handle only references the event loop when it's active. 'Active' means
different things for different handle types, e.g.:
* timers: ticking
* sockets: reading, writing or listening
* processes: always active (for now, subject to change)
* idle, check, prepare: only active when started
This commit also changes how the uv_ref() and uv_unref() functions work: they
now operate on the level of individual handles, not the whole event loop.
The Windows implementation was done by Bert Belder.
Use CLOCK_BOOTTIME to calculate the system uptime. Fall back to CLOCK_MONOTONIC
if CLOCK_BOOTTIME is not available (all pre-2.6.39 kernels).
The problem with CLOCK_MONOTONIC is that it doesn't increase when the system is
suspended, making the uptime differ from what the uptime(1) tool reports.
Previously, a new inotify fd was created for each watcher, making it quite easy
to run into the system-wide fs.inotify.max_user_instances limit (usually 128).
Fixes#300.
