This increases fs.WriteStream throughput dramatically by removing the
"higher default water marks" for fs.WriteStream.
Also includes a benchmark. Current performance is significantly higher
than v0.8 for strings at all tested levels except size=1. Buffer
performance is still lackluster.
Further improvement in the stream.Writable base class is required, but
this is a start.
Using external memory values allows for quick communication between js
and cc land, so we can check if the js land callback needs to be run.
(this is where I meant that manually tracking nextTickQueue.length would
be helpful)
Also did some minor cleanup of removing the old Tick and
StartTickSpinner functions, and a few unneeded comments.
Conflicts:
src/node.cc
* Callbacks from spinner now calls its own function, separate from the
tickCallback logic
* MakeCallback will call a domain specific function if a domain is
detected
* _tickCallback assumes no domains, until nextTick receives a callback
with a domain. After that _tickCallback is overridden with the domain
specific implementation.
* _needTickCallback runs in startup() instead of nextTick (isaacs)
* Fix bug in _fatalException where exit would be called twice (isaacs)
* Process.domain has a default value of null
* Manually track nextTickQueue.length (will be useful later)
* Update tests to reflect internal api changes
This reverts commit 0109a9f90a.
Also included: Port all the changes to process._makeCallback into the
C++ version. Immediate nextTick, etc.
This yields a slight boost in several benchmarks. V8 is optimizing and
deoptimizing process._makeCallback repeatedly.
* npm: Upgrade to v1.2.11
* http: Do not let Agent hand out destroyed sockets (isaacs)
* http: Raise hangup error on destroyed socket write (isaacs)
* http: protect against response splitting attacks (Bert Belder)
Prior to v0.10, Node ignored ECONNRESET errors in many situations.
There *are* valid cases in which ECONNRESET should be ignored as a
normal part of the TCP dance, but in many others, it's a very relevant
signal that must be heeded with care.
Exacerbating this problem, if the OutgoingMessage does not have a
req.connection._handle, it assumes that it is in the process of
connecting, and thus buffers writes up in an array.
The problem happens when you reuse a socket between two requests, and it
is destroyed abruptly in between them. The writes will be buffered,
because the socket has no handle, but it's not ever going to GET a
handle, because it's not connecting, it's destroyed.
The proper fix is to treat ECONNRESET correctly. However, this is a
behavior/semantics change, and cannot land in a stable branch.
Fix#4775
Running repl.start without the prompt set produces this error:
repl.js:95
throw new Error('An options Object, or a prompt String are required');
^
Error: An options Object, or a prompt String are required
at new REPLServer (repl.js:95:11)
at Object.exports.start (repl.js:321:14)
at Object.<anonymous> (/Users/dan/Dropbox/Documents/dev/nextgen/repl_test.js:5:6)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
Expose the file descriptor as a read-only property on the internal
handle objects. Intended for debugging purposes, not part of the API
proper. The property is always null on Windows.
Fixes#4754.
Previously, we were only destroying sockets on end if their readable
side had already been ended. This causes a problem for non-readable
streams, since we don't expect to ever see an 'end' event from those.
Treat the lack of a 'readable' flag the same as if it was an ended
readable stream.
Fix#4751
node 0.9.6 introduced Buffer changes that cause the key argument of
Hmac::HmacInit (used in crypto.createHmac) to be NULL when the key is
empty. This argument is passed to OpenSSL's HMAC_Init, which does not
like NULL keys.
This change works around the issue by passing an empty string to
HMAC_Init when the key is empty, and adds crypto.createHmac tests for
the edge cases of empty keys and values.
This is causing the CryptoStreams to get into an awful state when
there is a tight loop calling connection.write(chunk) waiting for
a false return.
Because CryptoStreams use read(0) to cycle data, this was causing
the encrypted side to pull way too much data in from the cleartext
side, since the read(0) would make it always call _read.
The unfortunate side effect, fixed in the next patch, is that
CryptoStreams don't automatically cycle when the Socket drains.
isaacs
Gil Pedersen
Trevor Norris
Shigeki Ohtsu
Ben Noordhuis
Dan Kohn
Fedor Indutny
Victor Costan