11d1eca9 added a v8 locker to ease development of 3rd party threading
extensions but it created a condition which would cause node to exit
uncleanly while in debug mode; it was reverted in 7543c38d.
The problem here is that the Locker was being disposed after V8 was torn
down. Adding some scoping fixes that.
* Upgrade V8 to 3.9.2
* Revert support for isolates. (Ben Noordhuis)
* cluster: Cleanup docs, event handling, and process.disconnect (Andreas Madsen)
* gyp_addon: link with node.lib on Windows (Nathan Rajlich)
* http: fix case where http-parser is freed twice (koichik)
* Windows: disable RTTI and exceptions (Bert Belder)
This simplify the internalMessage and exit event handling
And simply relay message and error event to the worker object
Note that the error event was not relayed before
It was decided that the performance benefits that isolates offer (faster spin-up
times for worker processes, faster inter-worker communication, possibly a lower
memory footprint) are not actual bottlenecks for most people and do not outweigh
the potential stability issues and intrusive changes to the code base that
first-class support for isolates requires.
Hence, this commit backs out all isolates-related changes.
Good bye, isolates. We hardly knew ye.
This reverts commit 11d1eca9f3.
It sporadically (but reproducibly) triggers an assert inside V8:
Fatal error in /path/to/node/deps/v8/src/isolate.cc, line 1857
CHECK(CurrentPerIsolateThreadData()->isolate_ == this) failed
Needs further investigation.
v8 requires a lock of each thread using the vm, but if none is
explicitly is created it will implicitly create one for you. This
creates issues when trying to build modules which use v8's
multi-threading features because there's no lock to unlock.
A ReadStream constructed from an existing file descriptor failed to start
reading automatically. Avoids a userspace call to ReadStream.prototype._read().
The base64 decoder would intermittently throw an out-of-bounds exception when
the buffer in `buf.write('', 'base64')` was a zero-sized buffer located at the
end of the slab.
Fixes#2657.
Honor the length argument in `buf.write(s, 0, buf.length, 'base64')`. Before
this commit, the length argument was ignored. The decoder would keep writing
until it hit the end of the buffer. Since most buffers in Node are slices of
a parent buffer (the slab), this bug would overwrite the content of adjacent
buffers.
The bug is trivially demonstrated with the following test case:
var assert = require('assert');
var a = Buffer(3);
var b = Buffer('xxx');
a.write('aaaaaaaa', 'base64');
assert.equal(b.toString(), 'xxx');
This commit coincidentally also fixes a bug where Buffer._charsWritten was not
updated for zero length buffers.
isaacs
Igor Zinkovsky
Ben Noordhuis
Nathan Rajlich
Andreas Madsen
Dave Pacheco
Marcel Laverdet
koichik
Bert Belder
Christopher Jeffrey
Stefan Rusu