Changes since version 0.10.20:

* unix: fix a possible memory leak in uv_fs_readdir (Alex Crichton)

Some scandir implementations allocate the dirent struct even if the
directory is empty, so if `scandir` returns 0 there may still be memory
that needs to get deallocated. I have altered uv__fs_readdir to go to
the "deallocation exit area" when 0 files are found in the directory
and continue to return early on a return value of -1.

I went to add a test for this functionality, but it appears that one
already exists (reading an empty directory), so I imagine that the
valgrind builds must only be happening on linux instead of OSX as well?
I have confirmed manually that a program without this fix will
infinitely leak memory, and with this fix the memory usage stays
constant.

Changes since version 0.10.19:

* linux: fix up SO_REUSEPORT back-port (Ben Noordhuis)

* fs-event: fix invalid memory access (huxingyi)

file_info->FileName is not null terminated.

The eclipse backend (like the ninja backend) does not support the
--generator_output switch.

Commit 3d2c820a back-ports a patch from the master branch that disables
the use of SO_REUSEPORT on Linux for reasons mentioned in the commit
log.

Unfortunately, the back-port was incomplete; another setsockopt() call
site in src/unix/udp.c was overlooked.  This commit rectifies that.

Hat tip to Luca Bruno for helping troubleshoot the issue.

The gyp build on Windows produces a *.pyc file as of commit 991409e4.

Back-port the test from commit 27795cfc from the master branch ("unix:
fix accept() EMFILE error handling").

Unbreak the build on the BSDs after commit bbccafbe.  Move the new
uv__platform_invalidate_fd() function from src/unix/darwin.c to
src/unix/kqueue.c.

Changes since version 0.10.18:

* darwin: avoid calling GetCurrentProcess (Fedor Indutny)

* unix: update events from pevents between polls (Fedor Indutny)

* fsevents: support japaneese characters in path (Chris Bank)

* linux: don't turn on SO_REUSEPORT socket option (Ben Noordhuis)

* build: fix windows smp build with gyp (Geert Jansen)

* linux: handle EPOLLHUP without EPOLLIN/EPOLLOUT (Ben Noordhuis)

* unix: fix reopened fd bug (Fedor Indutny)

* core: fix fake watcher list and count preservation (Fedor Indutny)

Fake watcher list and count should be preserved only if
`loop->watchers` was already allocated.

When fd is closed and new one (with the same number) is opened inside
kqueue/epoll/port loop's callback - stale events might invoke callbacks
on wrong watchers.

Check if watcher was changed after invocation and invalidate all events
with the same fd.

fix #826

Work around an epoll quirk where it sometimes reports just the EPOLLERR
or EPOLLHUP event.  In order to force the event loop to move forward,
we merge in the read/write events that the watcher is interested in;
uv__read() and uv__write() will then deal with the error or hangup in
the usual fashion.

Fixes #982.

This is a back-port of commit 24bfef2e from the master branch.

Gyp will try a parallel build if it detect the system has >1 processor.
This functionality depends on the Python "multiprocessing" package. The
multiprocessing package on Windows requires that the top-level module is
importable as a module, see:

  http://docs.python.org/2/library/multiprocessing.html#windows

This fixes issue #984.

This is a back-port of commit 24454678 from the master branch.

On the BSDs, SO_REUSEPORT is pretty much SO_REUSEADDR with some special
casing for IP multicast.  When two processes (that don't do multicast)
bind to the same address, only the last one receives traffic.  It allows
one to "steal" the bound address from another process.  (Both processes
have to enable SO_REUSEPORT though, so it only works in a cooperative
setting.)

On Linux however, it enables port sharing, not stealing - both processes
receive a share of the traffic.  This is a desirable trait but pre-3.9
kernels don't support the socket option and a libuv program therefore
behaves differently with older kernels or on another platform.

This is a back-port of commit 9d60f1eb from the master branch.

Fixes joyent/node#6454.

Watchers could be stopped between two `kevent()`/`epoll_wait()` calls
(which may happen in the same loop in `uv__io_poll()`), in such cases
`watcher->events` could be stale and won't be updated to
`watcher->pevents`.

Try to use and rely on `watcher->pevents` instead of blindly expecting
`watcher->events` to be always correct.

Use some black-magic from Apple to change process name without getting
a "Not responding" tag from Activity Manager.

fix #966

Changes since version 0.10.17:

* unix: fix uv_spawn() NULL pointer deref on ENOMEM (Ben Noordhuis)

* unix: don't close inherited fds on uv_spawn() fail (Ben Noordhuis)

* unix: revert recent FSEvent changes (Ben Noordhuis)

* unix: fix non-synchronized access in signal.c (Ben Noordhuis)

Check the return value of uv__signal_lock(); don't mutate the signal
watcher tree in the signal handler if we failed to acquire the lock.

This commit reverts the following commits:

    983fa68e darwin: fix 10.6 build error in fsevents.c
    684e2124 fsevents: use shared FSEventStream
    ea4cb778 fsevents: FSEvents is most likely not thread-safe
    9bae606d darwin: create fsevents thread on demand

Several people have reported stability issues on OS X 10.8 and bus
errors on the 10.9 developer preview.

See also joyent/node#6296 and joyent/node#6251.

The cleanup-after-error code path in uv_spawn() was closing file
descriptors indiscriminately.  Only close file descriptors that we
created ourselves, not the ones that are passed in by the user.

Fixes joyent/node#6297.

In the cleanup-after-error section of uv_spawn(), check that the pointer
is non-NULL - we might end up in said section due to a malloc() failure.

It turns out that node.js relies on the blocking behavior of pipes in
some cases, notably when forking worker processes.  Reopens #941.

This reverts commit 8fe4ca68.

Don't rely on the caller to set the O_NONBLOCK flag on the file
descriptor.

Prevents sporadic stalls when the file descriptor is in blocking mode
and exactly as many bytes are read as there are available; in that case,
libuv will try to read again and block.  Node.js was guilty of this.

Fixes #941.

Changes since version 0.10.16:

* build: remove GCC_WARN_ABOUT_MISSING_NEWLINE (Ben Noordhuis)

* darwin: fix 10.6 build error in fsevents.c (Ben Noordhuis)

Work around an 'initializer element is not constant' build error in
src/unix/fsevents.c by turning the const int flags into #defines.

Only an issue on OS X 10.6 due to the old compiler it uses.

Fixes #908.

This is a back-port of commit 82f2472b from the master branch.

Not compatible with non-Apple gcc builds.  Fixes the following build
error:

    gcc-4.8: error: unrecognized command line option '-Wnewline-eof'

Changes since version 0.10.15:

* windows: make uv_shutdown() for write-only pipes work (Bert Belder)

* windows: make uv_fs_open() report EINVAL when invalid arguments are
  passed (Bert Belder)

* windows: make uv_fs_open() report _open_osfhandle() failure correctly
  (Bert Belder)

* windows: make uv_fs_chmod() report errors correctly (Bert Belder)

* windows: wrap multi-statement macros in do..while block (Bert Belder)

Until now we assumed that _open_osfhandle() would set _doserrno on
failure. This assumption was very wrong in one obvious case, namely when
the CRT file descriptor table would fill up. In that case errno is set
to EMFILE, but GetLastError() returns zero - which makes sense because
it's not a win32 error but rather a CRT problem.

Before, when the user passed an invalid paramter to uv_fs_open, libuv
would detect this and call SET_REQ_RESULT to set the result value to -1.
SET_REQ_RESULT then stored whatever error code was returned by
GetLastError(), which would have no relationship to the actual problem,
and might as well be zero.

A couple of issues prevented uv_shutdown() from working correctly with
write-only pipes.

  * The pipe handle wasn't opened with the right permissions, so an
    attempt to probe the state of the write buffer would fail with
    ERROR_ACCESS_DENIED.

  * The pipe flags for child process stdio pipes were always set to
    UV_HANDLE_READABLE and UV_HANDLE_WRITABLE, even in cases where it
    was actually half-duplex.

  * There was no code path that lead to closing the pipe handle if the
    pipe was write-only.