> I don't think you want an event loop per core, that's back into the realm of concurrent madness, and I don't think that's how Erlang works (Erlang folk: correct me if I'm wrong on that).
If you don't care about performance, sure (there's nothing wrong with not caring about performance e.g.,: low volume web applications, where server side Javascript can shine, IMO). However, I can give you a command line you can run which will plot a very nice graph of throughput vs. number of selector threads in a specific system that I've been working on.
Yes, it will bring you back to "concurrent madness". What you _want_ is having primitives that make it possible to deal with this madness, not handwave it away. In Erlang they're actors themselves, optimized for efficient delivery of message within a single node and remotely, supervision of processes that fail, ETS, mnesia; in Java they're Doug Lea's beautiful concurrent collections (java.util.concurrent). You're assuming multi threading pthreads or synchronized/notify/wait (Java before java.util.concurrent).
Note that there are two models for this: one is Erlang's as well as traditional UNIX IPC -- message passing; the other is shared memory multi-threading with concurrent and lock free collections (Java), which also goes nicely with the idea of minimizing mutable state (Haskell, Clojure, Scala). One is good for one kinds of applications which optimize for worst case latency (Erlang shines there), the other is good for another, which optimize for average throughput (JVM shines there).
If you don't care about performance, sure (there's nothing wrong with not caring about performance e.g.,: low volume web applications, where server side Javascript can shine, IMO). However, I can give you a command line you can run which will plot a very nice graph of throughput vs. number of selector threads in a specific system that I've been working on.
Yes, it will bring you back to "concurrent madness". What you _want_ is having primitives that make it possible to deal with this madness, not handwave it away. In Erlang they're actors themselves, optimized for efficient delivery of message within a single node and remotely, supervision of processes that fail, ETS, mnesia; in Java they're Doug Lea's beautiful concurrent collections (java.util.concurrent). You're assuming multi threading pthreads or synchronized/notify/wait (Java before java.util.concurrent).
Note that there are two models for this: one is Erlang's as well as traditional UNIX IPC -- message passing; the other is shared memory multi-threading with concurrent and lock free collections (Java), which also goes nicely with the idea of minimizing mutable state (Haskell, Clojure, Scala). One is good for one kinds of applications which optimize for worst case latency (Erlang shines there), the other is good for another, which optimize for average throughput (JVM shines there).