Increase the performance and simplify the logic of Buffer#write{U}Int*
and Buffer#read{U}Int* methods by placing the byte manipulation code
directly inline.
Also improve the speed of buffer-write benchmarks by creating a new
call directly to each method by using Function() instead of calling by
buff[fn].
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Conflicts:
lib/buffer.js
This patch simplifies the implementation of StringDecoder, fixes the
failures from the new test cases, and also no longer relies on v8's
WriteUtf8 function to encode individual surrogates.
Currently, if fstat() fails in readFile(), the callback
is invoked without closing the file. This commit closes
the file before calling back.
Closes#7697
Ensure TypeError is thrown, fix a bug where `env` option was
assuming the option was actually an object.
This case is especially bad because it then sets `env == null`
instead of using `process.env`.
Fix#7456
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Before this commit the EventEmitter methods were anonymous functions.
V8 tries to infer names for anonymous functions based on the execution
context but it frequently gets it wrong and when that happens, the
stack trace is usually confusing and unhelpful. This commit names all
methods so V8 can fall back to the method.name property.
The above gotcha applies to all anonymous functions but is exacerbated
for EventEmitter methods because those are invoked with a plenitude of
different receivers.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Fix possible deadlock, when handles are sent in both direction
simultaneously. In such rare cases, both sides may queue their
`NODE_HANDLE_ACK` replies and wait for them.
fix#7465
Socket may become not `readable`, but http should not rely on this
property and should not think that it means that no data will ever
arrive from it. In fact, it may arrive in a next tick and, since
`this.push(null)` was already called, it will result in a error like
this:
Error: stream.push() after EOF
at readableAddChunk (_stream_readable.js:143:15)
at IncomingMessage.Readable.push (_stream_readable.js:123:10)
at HTTPParser.parserOnBody (_http_common.js:132:22)
at Socket.socketOnData (_http_client.js:277:20)
at Socket.EventEmitter.emit (events.js:101:17)
at Socket.Readable.read (_stream_readable.js:367:10)
at Socket.socketCloseListener (_http_client.js:196:10)
at Socket.EventEmitter.emit (events.js:123:20)
at TCP.close (net.js:479:12)
fix#6784
When sending a socket to a child process via IPC pipe,
`child_process.js` picks a raw UV handle from `_handle` property, sends
it, and assigns `null` to the property. Sending the same socket twice
was resulting in a runtime error, since we weren't handling the empty
`_handle` case.
In case of `null` `_handle` we should send just a plain text message
as passed it was passed to `.send()` and ignore the handle, letting
users handle such cases themselves instead of throwing the error at
runtime.
fix#5469
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.
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.
Ensure that the behavior of `assert.deepEqual` does not depend on
argument ordering when comparing an `arguments` object with a
non-`arguments` object.
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
Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue. Adds to #7070
("DNS — Throw meaningful error(s)").
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
Spawn's arguments were documented to be optional, as they are for the
other similar child_process APIs, but the code was missing. Result was
`child_process.spawn('node', {})` errored when calling slice() on an
Object, now it behaves as the documentation said it would.
domain.create().exit() should not clear the domain stack if the domain
instance does not exist within the stack.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
If a write is above the highWaterMark, _write still manages to
fully send it synchronously, _writableState.length will be adjusted down
to 0 synchronously with the write returning false, but 'drain' will
not be emitted until process.nextTick.
If another small write which is below highWaterMark is issued before
process.nextTick happens, _writableState.needDrain will be reset to false,
and the drain event will never be fired.
So we should check needDrain before setting it up, which prevents it
from inproperly resetting to false.
NOTE: Also removed `.receivedShutdown` method of `Connection` it wasn't
documented anywhere, and was rewritten with `true` after receiving
`close_notify`.
fix#6638
When calling `encOut` in loop, `maybeInitFinished()` may invoke
`clearOut`'s loop, leading to the writing of interleaved data
(encrypted and cleartext) into the one shared pool.
Move `maybeInitFinished()` out of the loop and add assertion for
future.
Check that `listeners` is actually an array before trying to manipulate it
because it won't be if no regular event listeners have been registered yet
but there are 'removeListener' event listeners.
Emitting an event within a `EventEmitter#once` callback of the same
event name will cause subsequent `EventEmitter#once` listeners of the
same name to be called multiple times.
var emitter = new EventEmitter();
emitter.once('e', function() {
emitter.emit('e');
console.log(1);
});
emitter.once('e', function() {
console.log(2);
});
emitter.emit('e');
// Output
// 2
// 1
// 2
Fix the issue, by calling the listener method only if it was not
already called.
Fix invalid `hasOwnProperty` function usage.
For example, before in the REPL:
```
> Ar<Tab>
Array
Array ArrayBuffer
```
Now:
```
> Ar<Tab>
Array
ArrayBuffer
```
Fixes#6255.
Closes#6498.
If a client sends a lot more pipelined requests than we can handle, then
we need to provide backpressure so that the client knows to back off.
Do this by pausing both the stream and the parser itself when the
responses are not being read by the downstream client.
Backport of 085dd30
Destroying the TLS session implies destroying the underlying socket but
before this commit, that was done with net.Socket#destroy() rather than
net.Socket#destroySoon(). The former closes the connection right away,
even when there is still data to write. In other words, sometimes the
final TLS record got truncated.
Fixes#6107.
Fedor Indutny
Nick Apperson
Brian White
Felix Geisendörfer
cjihrig
Alexis Campailla
Greg Sabia Tucker
Greg Sabia Tucker
Ben Noordhuis
Rod Vagg
isaacs
Fedor Indutny
Greg Brail
Nathan Rajlich
Mike Pennisi
Farid Neshat
Kenan Sulayman
iamdoron
Jun Ma
Timothy J Fontaine
Sam Roberts
Ryan Graham
ayanamist
Wyatt Preul
Kai Groner
Jeremy Martin
Tim Wood
Maciej Małecki
Maxim Bogushevich