unix: implicitly signal write errors to libuv user

Fix an infinite loop in the example below when the stream encounters
an EPIPE/ECONNRESET/etc. error:

    // keep writing until we start buffering
    while (stream->write_queue_size == 0) {
      uv_write_t* req = make_write_req();
      uv_buf_t buf = uv_buf_init("PING", 4);
      uv_write(req, stream, &buf, 1, write_cb);
    }

uv_write() does not return an error code on write errors, the error is
only reported to the callback.

Before this commit, uv_write() left stream->write_queue_size untouched
on error, meaning the caller had no way to find out about that error
until the next tick of the event loop - which in the example above
leads to an infinite loop because that next tick is indefinitely
postponed.

This commit works around that at the cost of some added internal
complexity.

Fixes joyent/node#5516.
unix: fix assert on signal pipe overflow

An incorrect assert() statement was causing libuv to crash when writing
to an internal signal pipe would result in EAGAIN/EWOULDBLOCK.

This commit doesn't solve the underlying issue that the signal pipe can
overflow.

This should fix joyent/node#5538
unix: fix stream refcounting buglet

Fix a buglet where uv_read_stop() would mark the handle as stopped even
when there are in-progress write requests.

This bug is unlikely to have affected anyone, the only case where it
has a user-visible effect is when:

  a) the handle has been stopped for reading but not writing, and
  b) it's the last active handle in the event loop's pollset

If both conditions are met, it's possible for the event loop to
terminate prematurely.
unix: turn off POLLOUT after stream connect

Clear the POLLOUT flag after we're done connecting. Not doing so isn't
really harmful but it may cause the event loop to wake up more often
than it has to.
Revert "unix: fix stream refcounting buglet"

This change is making 45 out of 527 node.js tests fail on OS X with the
following assertion:

    Assertion failed: (!uv__is_active(handle)), function
    uv__finish_close, file ../../deps/uv/src/unix/core.c, line 165.

It's likely a manifestation of a bug elsewhere but, because there's a
new node.js release going out tonight, I'm reverting it for now.

This reverts commit 80f2f826bf90b84e659321c0b7fd8af419acb85e.

Conflicts:
	src/unix/stream.c
2013.05.25, Version 0.10.8 (Stable)

Changes since version 0.10.7:

* windows: make uv_spawn not fail under job control (Bert Belder)

* darwin: assume CFRunLoopStop() isn't thread-safe (Fedor Indutny)

* win: fix UV_EALREADY incorrectly set (Bert Belder)

* darwin: make two uv__cf_*() functions static (Ben Noordhuis)

* darwin: task_info() cannot fail (Ben Noordhuis)

* unix: add mapping for ENETDOWN (Ben Noordhuis)

* unix: implicitly signal write errors to libuv user (Ben Noordhuis)

* unix: fix assert on signal pipe overflow (Bert Belder)

* unix: turn off POLLOUT after stream connect (Ben Noordhuis)
Now working on v0.10.9
unix: fix stream refcounting buglet

Fix a buglet where uv_read_stop() would mark the handle as stopped even
when there are in-progress write requests.

This bug is unlikely to have affected anyone, the only case where it
has a user-visible effect is when:

  a) the handle has been stopped for reading but not writing, and
  b) it's the last active handle in the event loop's pollset

If both conditions are met, it's possible for the event loop to
terminate prematurely.

This reapplies commit 80f2f82 which was temporarily reverted in fe7b154
because it was making a lot of node.js tests fail on OS X with the
following assertion:

    Assertion failed: (!uv__is_active(handle)), function
    uv__finish_close, file ../../deps/uv/src/unix/core.c, line 165.

Expecting that the handle is inactive when the state is UV_CLOSING
turns out to be a bad assumption: it's possible that the handle is
executing (for example) a shutdown request when uv__finish_close()
is called. That's okay, uv__stream_destroy() takes care of that.

The issue wasn't specific to OS X, it was just more visible on that
platform. (Slow) debug builds on Linux exhibited the same behavior.
unix: remove erroneous asserts

As of commit c53fe81, it's legal for write_queue_size > 0 when the
write_queue itself is empty. Sounds illogical but it means there are
error-state write requests in the write_completed_queue that will touch
up the write_queue_size on the next tick of the event loop.

Remove a few stray asserts that still checked for the old situation.
unix: add uv__is_closing() macro
unix: stop stream POLLOUT watcher on write error

The node.js test suite sometimes hits the assert that was added in
commit 4146805 that checks if there are connect, write or shutdown
requests pending when the user calls uv_read_stop() while the stream
is primed for writing.

The libuv user (i.e. node.js) is supposed to close the stream on error.
Because uv__stream_close() calls uv_read_stop(), it's possible that the
POLLOUT watcher is still active.
2013.05.29, Version 0.10.9 (Stable)

Changes since version 0.10.8:

* unix: fix stream refcounting buglet (Ben Noordhuis)

* unix: remove erroneous asserts (Ben Noordhuis)

* unix: add uv__is_closing() macro (Ben Noordhuis)

* unix: stop stream POLLOUT watcher on write error (Ben Noordhuis)
Now working on v0.10.10
include: document uv_update_time() and uv_now()
linux: fix cpu model parsing on newer arm kernels

The format of /proc/cpuinfo on ARM kernels >= 3.8 has changed. Scan for
the string "model name" (like x86) first, "Processor" second.

Fixes #812.
linux: fix memory leak in uv_cpu_info() error path

Any memory allocated to hold CPU model strings wasn't freed on error.
linux: don't ignore OOM errors in uv_cpu_info()
unix, windows: move uv_now() to uv-common.c
test: use c-style comments

Fixes a compilation problem on OS X caused by the use of c++-style
comments in test-osx-select.c.
darwin: make uv_fs_sendfile() respect length param

The darwin sendfile implementation uses the &len parameter as input
and output. The code was sending 0 (not using the value of req->len)
so the behavior wasn't what the caller was expecting.

This makes sure to initialize len with req->len to ensure that the
caller can send portions of a file (not always everything to the
end of the file).