2013.08.22, Version 0.10.14 (Stable)

Changes since version 0.10.13:

* unix: retry waitpid() on EINTR (Ben Noordhuis)
Now working on v0.10.15
darwin: create fsevents thread on demand

* Move CF run loop code to fsevents.c.

* Create the fsevents thread on demand rather than at startup.

* Remove use of ACCESS_ONCE. All accesses to loop->cf_loop are
  protected by full memory barriers so no reordering can take place.

Fixes #872.

Conflicts:
	src/unix/darwin.c
fsevents: FSEvents is most likely not thread-safe

Perform all operation with FSEventStream in the same thread, where it'll
be used.

Conflicts:
	src/unix/fsevents.c
fsevents: use shared FSEventStream

It seems that number of simultaneously opened FSEventStreams is
limited on OSX (i.e. you can have only fixed number of them on
one running system), getting past through this limit will cause
`FSEventStreamCreate` to return false and write following message
to stderr:

    (CarbonCore.framework) FSEventStreamStart: register_with_server:
    ERROR: f2d_register_rpc() => (null) (-21)

To prevent this, we must use only one shared FSEventStream with a
paths for all uv_fsevent_t handles, and then filter out events for
each handle using this paths again.

See https://github.com/joyent/node/issues/5463

Conflicts:
	include/uv-private/uv-darwin.h
	src/unix/fsevents.c
2013.08.24, Version 0.10.15 (Stable)

Changes since version 0.10.14:

* fsevents: create FSEvents thread on demand (Ben Noordhuis)

* fsevents: use a single thread for interacting with FSEvents, because
  it's not thread-safe. (Fedor Indutny)

* fsevents: share FSEventStream between multiple FS watchers, which
  removes a limit on the maximum number of file watchers that can be
  created on OS X. (Fedor Indutny)
Now working on v0.10.16
windows: make uv_fs_chmod() report errors correctly

Before this patch libuv would attempt to use GetLastError() to retrieve
the cause of NtQueryInformationFile failure, but that's not how it
should be done.
windows: make uv_shutdown() for write-only pipes work

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.
windows/fs: wrap multi-statement macros in do..while block
windows/fs: make uv_fs_open() report EINVAL correctly

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.
windows/fs: handle _open_osfhandle() failure correctly

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.
2013.09.06, Version 0.10.16 (Stable)

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)
Now working on v0.10.17
build: remove GCC_WARN_ABOUT_MISSING_NEWLINE

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

    gcc-4.8: error: unrecognized command line option '-Wnewline-eof'
darwin: fix 10.6 build error in fsevents.c

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 82f2472 from the master branch.
2013.09.25, Version 0.10.17 (Stable)

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)
Now working on v0.10.18
unix: set O_NONBLOCK in uv_pipe_open()

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.
Revert "unix: set O_NONBLOCK in uv_pipe_open()"

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 8fe4ca686bcb069f670b0381e89c008ca814f8ba.