This test setups two event listeners: one on a child process' exit event
, another for the same child process' stdandard output's 'data' event.
The data even listener writes to a stream, and the exit event listener
ends it.

Because the exit event can be emitted before the data event, there is a
chance that something will be written to the stream after it's ended,
and that an error is thrown.

This change makes the test end the stream in the listener for the child
process' standard output's end event, which is guaranteed to be emitted
after the last data event, thus avoiding the race.

PR: #9301
PR-URL: #9301
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@users.noreply.github.com>
Reviewed-By: Bert Belder <bertbelder@gmail.com>

PR: #9297
PR-URL: #9297
Reviewed-By: Julien Gilli <julien.gilli@joyent.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

The -fno-strict-aliasing flag was added to fix compilation warnings when
building Node.js with GCC <= 4.4

process.send() should be synchronous, it should block until the message
has been sent in full, but it wasn't after the second-to-last libuv
upgrade because of commit libuv/libuv@393c1c5 ("unix: set non-block
mode in uv_{pipe,tcp,udp}_open"), which made its way into io.js in
commit 07bd05b ("deps: update libuv to 1.2.1").

Commit libuv/libuv@b36d4ff ("unix: implement uv_stream_set_blocking()")
as landed in io.js in commit 9681fca ("deps: update libuv to 1.4.0")
makes it possible to restore the synchronous behavior again and that's
precisely what this commit does.

The same line of reasoning applies to `net.Socket({ fd: 1 })`: creating
a socket object from a stdio file descriptor, like the `process.stdout`
getter does, should put the file descriptor in blocking mode for
compatibility reasons.

PR-URL: nodejs/node#774
Reviewed-by: Trevor Norris <trev.norris@gmail.com>

Float patch to fix pipe on Windows. Original commit message:

  win: fix pipe blocking writes

  In the code path for pipe blocking writes, WriteFile is already
  posting a completion packet to the I/O completion port.
  POST_COMPLETION_FOR_REQ was causing the same request to get
  returned twice by GetCompletionStatusEx.
  Also on the same code path, we were waiting on the wrong event.

  We need to update queued_bytes and write_queue_size when a
  blocking write request completes asynchronously.

Ref: libuv/libuv#238