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.
linux: don't turn on SO_REUSEPORT socket option

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.

The difference in behavior (sharing vs. stealing) is, in my opinion,
big enough and confusing enough that it merits a rollback.  People
that want this kind of functionality can prepare the socket manually
and hand it off to uv_udp_open().

This commit effectively reverts commit 17452cd.
include: update uv_udp_open() / uv_udp_bind() docs

Mention that:

* these functions set the SO_REUSEADDR and SO_REUSEPORT socket flags,
* what the effect of those flags is, and
* that we may remove it someday
Revert "build: remove mingw makefile"

As requested by the Rust people.

This reverts commit 8f3621e4dd2d55befd0f0b8635cf8de17f849aff.
unix, windows: add thread-local storage API

Uses the pthread_key_{create,delete} and pthread_{get,set}specific
functions on UNIX platforms, Tls{Alloc,Free} and Tls{Get,Set}Value
on Windows.

Fixes #904.
windows: tweak Makefile.mingw for easier usage

Default CC to `gcc` instead of `cc` because at least on the mingw
installation I had there was no `cc` executable. This avoids having
to type `CC=gcc` in all the `make` commands.

Also append to `CFLAGS` instead of defining if not previously defined.
These flags are required to build libuv, so they should not be
overridden if other extra CFLAGS are supplied via the command
line as well.
windows: fix mingw build

On older mingw installations, DEVICE_TYPE isn't defined. This was
redefined in windows.h, but it was done after it was already attempted
to be used. This moves the #define for DEVICE_TYPE above the usage of
it in windows.h to prevent compilation failures.
unix: req queue must be empty when destroying loop

Assert that the request queue is empty when destroying the event loop.

Should catch errors where people call uv_loop_delete() when there are
still in-progress work requests (for example.)
unix: move loop functions from core.c to loop.c

Move uv_default_loop(), uv_loop_new() and uv_loop_delete() to loop.c.
darwin: remove CoreFoundation dependency

Load the required symbols at run-time rather than linking against the
CoreFoundation (and CoreServices and ApplicationServices) frameworks
at build time.

Should make integration easier for people that bundle libuv with their
own projects because they no longer have to replicate magic -framework
incantations in their top-level build system.
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.
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: 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.