JS 1.5: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip...
JS 1.6: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip...
JS 1.7: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip... <- generators, iterators, and more
JS 1.8: https://developer.mozilla.org/en/JavaScript/New_in_JavaScrip...
(As a side note, I once implemented Twisted's inlineCallbacks in JS 1.7; this worked because it had those Python-like generators. Too bad it doesn't work anywhere but SpiderMonkey.)
That library gives you coroutine-style I/O on top of node.js primitives, which is, as far as I can tell, the #1 feature people have been asking for all along in Node. It only works if node.js implements coroutines (which Ryan has so far refused to do) or if the language implements generators (which you get with SpiderMonkey).
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.
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!
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.
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.