Concurrency

One should probably try to follow the WebWorkers API as far as it makes sense on the server.

However, WebWorkers cannot share state, they can only communicate via messages, so if traditional threads are desired they are not acceptable.

And traditional threads are generally considered deprecated in modern language design. The WebWorkers design was intentional.

• Intel's River Trail uses "ParallelArray" and elemental functions to address them. There's a prototype build as a Firefox extension. Java JSR-166y embraces this approach, and it's a standard part of Java 7. A Rhino implementation "should" be easy.

• Synchronet's load() method supports creating background tasks/threads and implements a bidirectional Queue object which may be used to communicate with the concurrently executing child script: http://synchro.net/docs/jsobjs.html#Queue

A possible alternative is a stronger eventing dispatch mechansim. Actionscript did lots of good work in this area. Here is a set of event, listener and timer classes from Ejscript. These can be retro fitted to interpreters for which threads and threading are problematic or impossible.

• JSAPI threading https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference#Threading
• NSPR threads https://developer.mozilla.org/en/NSPR_API_Reference#Threads
• NSPR in general https://developer.mozilla.org/en/NSPR_API_Reference
• JavaScript Strands adds coroutine and cooperative threading support to the JavaScript language http://www.xucia.com/strands-doc/index.html
• Erlang-style concurrency with JavaScript 1.7 http://www.beatniksoftware.com/erjs/index.html
• Threading in Javascript 1.7 http://www.neilmix.com/2007/02/07/threading-in-javascript-17/
• NodeJS makes a strong argument about doing concurrent I/O with an event loop. The implementation uses threadpools to work around synchronous APIs, but these are all hidden from the user. The user APIs are all asynchronous using callbacks and promises.