The v8 team apparently decided that all build products should go
into ./build/«type», and updated their common.gypi file to do so.
Unfortunately v8's common.gypi is only used for some targets. All
the other targets would still look in the old place to find their
their dependencies, which effectively broke the build.
In the long run it would be good for node to send all build
output to ./build too, on all platforms.
This commit enables ETW events to be fired on Windows for existing
DTrace probes. ETW instrumentation is enabled by default. It
is possible to build node.exe without ETW instrumentation by
using --without-etw option with configure script.
It wasn't waiting for the child process' stderr to close, so not an
assertion was made *before* all the data that the child process sent
was received by node.
This implements server.listen({ fd: <filedescriptor> }). The fd should
refer to an underlying resource that is already bound and listening, and
causes the new server to also accept connections on it.
Not supported on Windows. Raises ENOTSUP.
The test would fail if the child process writes anything to the stdout.
This doesn't happen on unix, since `cat` is spawned. However, on Windows
`cmd` is started, which *does* write stuff to it's stdout. This
meanlingless assert is now removed.
* When the process is already dead, but the `exit` signal wasn't raised
yet, the ESRCH error should be ignored.
* When an invalid signal is specified, kill() should throw.
* Like process.kill(), child_process.kill() now preserves a `0` signal
which can be used to check the liveliness of the child process.
* process.kill() and child_process.kill() will now return true if the
signal was actually delivered, and false otherwise.
* When an `exec`-ed process is automatically killed because a time or
buffer limit is exceeded, and the kill() fails, this error should be
reported through the `exec` callback.
Fixes: #3409
In Windows the callbacks arrive in slightly different order. A bunch
of write operations complete immediately, and after that there is a
gap of a few hundred ms. This causes the timeout timer to fire, which
is not really warranted; the first few write operations just finished a
little quicker than expected.
