Internally we use hrtime to schedule when a timer will fire, to avoid
the perils of clock drift or other external operation making time go
backward. The timers ordering test should use the same timing mechanism
If two timers run on the same tick, and the first timer uses a domain,
and then catches an exception and disposes of the domain, then the
second timer never runs. (And even if the first timer does not dispose
of the domain, the second timer could run under the wrong domain.)
This happens because timer.js uses "process.nextTick()" to schedule
continued processing of the timers for that tick. However, there was
an exception inside a domain, then "process.nextTick()" runs under
the domain of the first timer function, and will do nothing if
the domain has been disposed.
To avoid this, we temporarily save the value of "process.domain"
before calling nextTick so that it does not run inside any domain.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
Unlike the 'exit' event, this event allows the user to schedule more
work and thereby postpone the exit. That also means that the
'beforeExit' event may be emitted many times, see the attached test
case for an example.
Refs #6305.
Don't invoke the `agent.requst()` or `agent.get()` functions
directly. Instead, use the public API and pass the agent
instance in as the `agent` option.
This makes it so that the user may pass in a
`createConnection()` option, and they don't have
to pass `agent: false` at the same time.
Also adding a test for the `createConnection` option,
since none was in place before.
See #7014.
Expose `setBlocking` on Pipe's and if a pipe is being created for stdio
on windows then make the pipes blocking.
This fixes test-stream2-stderr-sync.js on Windows.
Fixes#3584
One test case in test-stream2-stderr-sync.js was creating a TTY
object using an undocumented constructor and passing in fd 2.
However, this is running in a child process and fd 2 is actually
a pipe, not a TTY.
The constructor fails on Windows and causes the handle type to be
left uninitialized, which later causes an assert to fail.
On Unix, the constructor fails to retrieve the windows size but unlike
on Windows, it just leaves the size fields undefined and continues
with initializing the stream type, yielding a semi-usable object.
I could make the Windows version match Unix behavior, but it
seems to me that the test is relying on an implementation detail of
an undocumented API, and the Unix behavior is not necessarily more
correct than the Windows one. Thus it makes more sense to remove this
test.
Ensure that the behavior of `assert.deepEqual` does not depend on
argument ordering when comparing an `arguments` object with a
non-`arguments` object.
This test is particularly pathological, and requires a ton of time to
run, we need to find a better way to manage it but in general this path
is fairly safe these days.
bufferSize is now a getter that shows all that has not been
acknowledged by the os, as well as in the buffer state. The test is
only looking to verify the js verified state.
Scheduling of next ticks from within the next tick handler will result
in a tight execution loop where a timer cannot break into.
This test was invalid
We were being very aggressive in our connection creations, resulting
in the pipeline flood detection to drop us. Relax how fast we're
creating these connections so the gc can run all its tests.
Expose localPort for binding to a specific port for outbound
connections.
If localAddress is not specified '0.0.0.0' is used for ip4 and '::'
for ip6 connections.
Fixes#7092
The reason this wasn't working was because after restart, when restoring
breakpoints the scripts wasn't loaded, so the breakpoint.script was
undefined. As a fix I added another check to use breakpoint.scriptReq
instead of breakpoint.script, which is the same except when the
breakpoint is a function.
fixes#7027
If an input stream would emit `end` event, like
`fs.createReadStream`, then readline need to get the last line
correctly even though that line isnt ended with `\n`.
Given the assert message, and the fact that endCb is always true
in the assert, I am pretty sure the test author was intending
to test for finishEvent, not endCb.
In this test, an HTTP server was ending the response before
consuming all the data sent in the PUT request.
Ending the response would cause the socket to be destroyed,
and since there is some data still to be read, an ECONNRESET is
surfaced on the client side, event though the client has already
ended its side and even seen a 'finish' event.
See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2
While it is certainly admissible for the server to send a response
before consuming the entire request, it seems reasonable to
expect that the server would close the connection afterwards
and that the ECONNRESET would be raised on the client.
So I have changed the test to wait until the entire request has been
consumed before sending the response.
This implements the user-facing APIs that lets one run a child process
and block until it exits.
Logic shared with the async counterpart of each function was refactored
to enable code reuse.
Docs and tests are included.
Timothy J Fontaine
Fedor Indutny
Vladimir Kurchatkin
Brian White
Benoit Vallée
Greg Brail
Sam Roberts
Ben Noordhuis
Nathan Rajlich
Trevor Norris
Alexis Campailla
Mike Pennisi
David Björklund
Farid Neshat
Yazhong Liu
orangemocha@github.com