Commit 9352c19 ("child_process: don't emit same handle twice") trades
one bug for another.
Before said commit, a handle was sometimes delivered with messages it
didn't belong to.
The bug fix introduced another bug that needs some explaining. On UNIX
systems, handles are basically file descriptors that are passed around
with the sendmsg() and recvmsg() system calls, using auxiliary data
(SCM_RIGHTS) as the transport.
node.js and libuv depend on the fact that none of the supported systems
ever emit more than one SCM_RIGHTS message from a recvmsg() syscall.
That assumption is something we should probably address someday for the
sake of portability but that's a separate discussion.
So, SCM_RIGHTS messages are never coalesced. SCM_RIGHTS and normal
messages however _are_ coalesced. That is, recvmsg() might return this:
recvmsg(); // { "message-with-fd", "message", "message" }
The operating system implicitly breaks pending messages along
SCM_RIGHTS boundaries. Most Unices break before such messages but Linux
also breaks _after_ them. When the sender looks like this:
sendmsg("message");
sendmsg("message-with-fd");
sendmsg("message");
Then on most Unices the receiver sees messages arriving like this:
recvmsg(); // { "message" }
recvmsg(); // { "message-with-fd", "message" }
The bug fix in commit 9352c19 assumes this behavior. On Linux however,
those messages can also come in like this:
recvmsg(); // { "message", "message-with-fd" }
recvmsg(); // { "message" }
In other words, it's incorrect to assume that the file descriptor is
always attached to the first message. This commit makes node wise up.
Fixes#5330.
This adds proper support for the following situation:
w.cork();
w.write(...);
w.cork();
w.write(...);
w.uncork();
w.write(...);
w.uncork();
This is relevant when you have a function (as we do in HTTP) that wants
to use cork, but in some cases, want to have a cork/uncork *around*
that function, without losing the benefits of writev.
In synchronous Writable streams (where the _write cb is called on the
current tick), the 'finish' event (and thus the end() callback) can in
some cases be called before all the write() callbacks are called.
Use a counter, and have stream.Transform rely on the 'prefinish' event
instead of the 'finish' event.
This has zero effect on most streams, but it corrects an edge case and
makes it perform more deterministically, which is a Good Thing.
uv_async_t handles for dispatching of debug messages and
emitting NODE_DEBUG_ENABLED used to be initialized every time
node::EnableDebug() was called, which happened every time
user sends a SIGUSR1.
Now they are initialized only once from node::Init() during
application start.
Implement support for debugging cluster workers. Each worker process
is assigned a new debug port in an increasing sequence.
I.e. when master process uses port 5858, then worker 1 uses port 5859,
worker 2 uses port 5860, and so on.
Introduce new command-line parameter '--debug-port=' which sets debug_port
but does not start debugger. This option works for all node processes, it
is not specific to cluster workers.
Fixesjoyent/node#5318.
Preserve default install prefix seen in process.config, but use DESTDIR
for installing to deliniate 32/64 versions, avoid conflicts with PREFIX
settings in config.mk
Preserve default install prefix seen in process.config, but use DESTDIR
for installing to deliniate 32/64 versions, avoid conflicts with PREFIX
settings in config.mk
Change vcbuild.bat to ignore VCINSTALLDIR environment variable,
always check for specific VS version and set GYP_MSVS_VERSION
accordingly. Otherwise GYP generates project files in format
that cannot be compiled by VS2012.
When developer calls setBreakpoint with an unknown script name,
we convert the script name into regular expression matching all
paths ending with given name (name can be a relative path too).
To create such breakpoint in V8, we use type `scriptRegEx`
instead of `scriptId` for `setbreakpoint` request.
To restore such breakpoint, we save the original script name
send by the user. We use this original name to set (restore)
breakpoint in the new child process.
This is a back-port of commit 5db936d from the master branch.
After much investigation it turns out that the affected servers are
buggy. user-service.condenastdigital.com:443 in particular seems to
reject large TLS handshake records. Cutting down the number of
advertised ciphers or disabling SNI fixes the issue.
Similarly, passing { secureOptions: constants.SSL_OP_NO_TLSv1_2 }
seems to fix most connection issues with IIS servers.
Having to work around buggy servers is annoying for our users but not
a reason to downgrade OpenSSL. Therefore, revert it.
This reverts commit 4fdb8acdaef4c3cb1d855e992ada0e63fee520a6.
Add a watchdog class which executes a timer in a separate event loop in
a separate thread that will terminate v8 execution if it expires.
Add timeout argument to functions in vm module which use the watchdog
if a non-zero timeout is specified.
This commit undoes the downgrade from OpenSSL v1.0.1e to v1.0.0f,
effectively upgrading OpenSSL to v1.0.1e again. The reason for the
downgrade was to work around compatibility issues with certain TLS
servers in the stable branch. See the commit log of 4fdb8ac and the
linked issue for details. We're going to revisit that in the master
branch.
This reverts commit 4fdb8acdaef4c3cb1d855e992ada0e63fee520a6.
Forward-port the comments from commit 01e2920 (v0.10) to the master
branch. Everything else from that patch already exists in master.
It didn't merge cleanly because lib/http.js has been split up in
several files.
