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.
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.
uv_thread_self() is difficult to implement on Windows in a way where the return
value is valid across threads. It's already been removed from upstream libuv.
Speeds up the benchmark below by about 680% (0.5s versus 3.4s on my Core 2 Duo).
var crypto = require('crypto');
var hash = crypto.createHash('sha1');
var data = new Buffer(1024);
for (var i = 0; i < 128 * 1024; ++i) hash.update(data);
Fixes#2494.
Parent and child isolates can now pass arbitrary binary messages between each
other. The messages are sent and received through a thread-safe queue that
wakes up the event loop of the receiving thread.