[bnoordhuis]

V8 is a single-threaded VM and I don't see that changing any time soon, it's very much married to Chrome's per-process model. SpiderMonkey doesn't have that drawback, it supports threads just fine.

These guys have their work cut out for them if they want to support the V8 API from within SM. It's a well designed API but large and fast moving.

Still, an interesting project. I'm going to watch it, maybe submit a few patches.

[udp]

I had some problems with SpiderMonkey's thread safe mode. If you have your own lock system, and you lock a resource while running JS, SM might do garbage collection at any time, for which it has its own lock. This causes deadlock very quickly indeed.

I had to resort to having a pool of JS runtimes from which each thread would borrow a runtime when it wanted to execute code, and return it when it was finished. This got messy quickly when I found out that script objects can't be shared, and I needed to load an individual copy of each script for each runtime.

Furthermore, JS objects weren't able to be shared between threads even when I didn't have separate runtimes, and I needed to (this was actually the recommended approach) write them to a binary format using JS_WriteStructuredClone when one thread was finished with them, and reassemble them with JS_ReadStructuredClone on the other end.

In the end, I gave up trying to do multithreaded Javascript and went for a nice, single threaded event driven model. I don't regret it. Heck, since it's lock-free - and structured clone free - it's probably more scalable!

[bnoordhuis]

I hear you, threading in SM is indeed fraught with dangers.

On the off chance that you're going to revisit it, the way to go is to compile with -DJS_THREADSAFE and register a callback with JS_SetGCCallback() that tells the VM when it's safe to run the garbage collector.

Actually, the approach I took was to always tell the VM 'no' and invoke JS_GC() manually from time to time. Conceptually easy and performance is mostly amortized.

PS: Feel free to contact me if you have follow-up questions, my email is in my profile.

[mraleph]

I think Mozilla is also making SpiderMonkey threading model more strict. https://developer.mozilla.org/en/JS_THREADSAFE says:

JS_THREADSAFE is now permanently on.

We have recently made major changes to this feature. Until recently, sharing objects among threads would mostly work, although scripts could easily make it crash. We have now completely removed that feature. Each thread that uses the JavaScript engine must essentially operate in a totally separate region of memory.

------

So both VMs provide essentially the same multithreading capabilities.

[vr]

V8 supported multiple threads since long ago using a big VM lock approach (v8::Locker). Since 3.2.4 it's possible to run independent V8 code in parallel using the new v8::Isolates API: http://code.google.com/p/v8/source/browse/trunk/include/v8.h...

[zpao]

If you're interested in helping out, best thing to do is stop by the IRC channel and see what we need the most help with (or if you want to start more simple, we can point you at that too). We've been moving pretty quickly in the week since that went up.

[davidden]

http://www.realseocompany.com/ http://www.realseocompany.com/local-seo-company/ http://www.realseocompany.com/our-services/ http://www.realseocompany.com/our-services/seo-marketing/ http://www.realseocompany.com/seo-marketing-services/