What about using a JVM with green threads support or Quasar,
wouldn't it be more comparable?
--
Paulo
Long text, contents of common interest in the last section :-)
Thanks for the hints, Paulo. Quasar looks interesting. The
current number one actor implementation for the JVM is Akka
(akka.io). It was earlier built on Hawtdispatch
(https://github.com/fusesource/hawtdispatch), which is similar to
Quasar but much simpler. Now they have plugged in their own
scheduler. Those libraries follow the same approach that a small
number of threads (small to make the overhead of context switches
small) serve a large number of consumers (e.g., channels, actors,
or whatever consumer abstraction). This works well as long as all
tasks are short-runners. It becomes a problem once you have many
long-runners. Me talking about large fibonacci numbers in my
previous post was to indicate that it is all about the problem
with long-runners. In Vert.x they have a separate scheduler for
long-runners that can serve a certain number of tasks and rejects
tasks once the max is exceeded. I will check out have they have
implemented channel select in Quasar. In Go they can do this
efficiently, because it is done by the built-in scheduler and not
in the library.
As what D is concerned it has vibe.d, which follows on principle
the same approach as described above from what I understand about
it. There is an old discussion about integrating vibe.d in the D
distribution. This way multi-threading in D comes with batteries
included as in Go. I still think this is a good idea :-).
