Changes since version 0.11.18:

* linux: move sscanf() out of the assert() (Trevor Norris)

* linux: fix C99/C++ comment (Fedor Indutny)

Conflicts:
	ChangeLog
	src/unix/linux-core.c
	src/version.c

If asserts are turned off then the sscanf() wouldn't have run, being
placed directly in the assert() itself.

Changes since version 0.11.17:

* osx: Fix a possible segfault in uv__io_poll (Alex Crichton)

* windows: improved handling of invalid FDs (Alexis Campailla)

* doc: adding ARCHS flag to OS X build command (Nathan Sweet)

* tcp: reveal bind-time errors before listen (Alexis Campailla)

* tcp: uv_tcp_dualstack() (Fedor Indutny)

* linux: relax assumption on /proc/stat parsing (Luca Bruno)

* openbsd: fix obvious bug in uv_cpu_info (Fedor Indutny)

* process: close stdio after dup2'ing it (Fedor Indutny)

* linux: move sscanf() out of the assert() (Trevor Norris)

Conflicts:
	AUTHORS
	src/version.c

If asserts are turned off then the sscanf() wouldn't have run, being
placed directly in the assert() itself.

This reverts commit 5008f8de.

When building using gyp and BUILDTYPE=Release using clang 3.4 received
this warning:

../src/unix/linux-core.c:640:34: warning: variable 'n' is uninitialized
      for (len = sizeof("cpu0"); n /= 10; len++);
                                 ^

Initializing n = 0 silences this build warning.

Changes since version 0.10.22:

* linux: relax assumption on /proc/stat parsing (Luca Bruno)

* openbsd: fix obvious bug in uv_cpu_info (Fedor Indutny)

* process: close stdio after dup2'ing it (Fedor Indutny)

Conflicts:
	ChangeLog
	src/unix/process.c
	src/version.c

Thus allow passing the same file descriptor as the source of multiple
stdios.

Committed with the help and code parts from:

  * Sam Roberts <sam@strongloop.com>

fix #1074

`int which[]` should not be static here, as the function itself is
changing it

fix joyent/node#6878

CPU entries in /proc/stat are not guaranteed to be monotonically
increasing, asserting on this assumption can break in cases such
as the UltraSparc II machine shown in #1080.

Signed-off-by: Luca Bruno <lucab@debian.org>

Explicitly disable/enable dualstack depending on presence of flag set by
uv_tcp_dualstack() function.

Changed uv_tcp_duplicate_socket to reveal any bind-time errors
before calling listen().

This fix is 100% windows specific.

It helps fix Node.js unite test test-cluster-bind-twice on Windows.

Adding further instructions about building for OS X, as recent versions
of xcodebuild will automatically build for i386 (can someone say,
"monoculture") even on x86_64 machines! Specifically including
instructions about including the "ARCHS" flag to specify the right
architecture.

This is trivial, but will save people time.

If passed and invalid FD, _get_osfhandle() sets an error code
through errno, not _doserrno. Hence we need to use
SET_REQ_WIN32_ERROR insted of SET_REQ_RESULT.

In debug builds, _get_osfhandle() also raises a superfluous
assert. I implemented a wrapper that disables all asserts
around the call to _get_osfhandle().

This fixes node.js unit tests test-fs-read-stream.js and
test-listen-fd-ebadf.js.

Changes since version 0.10.21:

* windows: avoid assertion failure when pipe server is closed (Bert
  Belder)

Changes since version 0.11.16:

* stream: allow multiple buffers for uv_try_write (Fedor Indutny)

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

* unix, windows: add uv_loop_alive() function (Sam Roberts)

* windows: avoid assertion failure when pipe server is closed (Bert
  Belder)

* osx: Fix a possible segfault in uv__io_poll (Alex Crichton)

* stream: fix uv__stream_osx_select (Fedor Indutny)

uv__stream_osx_interrupt_select was only defined on OS X, but is used
elsewhere on all platforms.  The intention was to implement it as a
no-op on other platforms, but the entire definition was inside
"#ifdef __APPLE__", so this didn't actually work.

Fix: move it above the #ifdef.

Relying on `readable`/`writable` when polling will lead to the select
thread spinning in the loop and calling `uv_async_send()`, because
stream may never become not `readable`/`writable`.

We should rely on `uv__io_active()` instead and interruprt select thread
every time it changes.

The commit is quite broken and must be refactored before going into.

This reverts commit 08aeaf61.

If multiple handles arrive to the IPC pipe at the same time (happens on
some platforms), libuv will queue them internally, and call `read2_cb`
multiple times with a null-buffer and proper `handle_type`.

In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.

As concrete evidence, here is the situation that I found caused the
segfault.  The instruction in question along with the relevant register
values was:

    mov    (%r8,%r15,8),%r12

    r8  = 0x7fb0ba800000
    r15 = 0xffffffffffffffff

    r8 + r15 * 8 == 0x7fb0ba7ffff8

It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.

In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.

As concrete evidence, here is the situation that I found caused the
segfault.  The instruction in question along with the relevant register
values was:

    mov    (%r8,%r15,8),%r12

    r8  = 0x7fb0ba800000
    r15 = 0xffffffffffffffff

    r8 + r15 * 8 == 0x7fb0ba7ffff8

It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.

Conflicts:
	build.mk
	Makefile.am
	test/test-ipc.c

When a server and a client are both part of the same event loop, and
the client connects to the server, the order in which the connect
callback and the connection callback are called is unspecified.
Apparently on linux the connection callback sometimes happens first,
which is not a bug, and should not make this test fail.

Add a regression test for the pipe server close issue on Windows, which
was reported in joyent/node#6749 and fixed in 7b16a3f5.

Conflicts:
	AUTHORS
	ChangeLog
	src/version.c

When a pipe server is closed, all pending accept requests and their
associated HANDLEs are closed to force windows to cancel the
ConnectNamedPipe IRP. The returned request has the `pipeHandle` field
set to INVALID_HANDLE_VALUE, which trips an assert in
uv_pipe_process_accept_req. This patch fixes that.