I keep reading from lots of people that you can't bolt Erlang's concurrency model on Ruby. But is this really true? MRI already has green threads. Adding a higher level of concurrency with the basic primitives of !, recv and spawn doesn't seem like a gigantic project. The main problem would be to prohibit access to shared memory between the spawned green threads, and avoid the GIL. But that doesn't seem to be that large of a problem. The main question is rather if this model would fit well with the Ruby language... Since Erlang was designed from the ground up with these primitives in mind, many of the libraries and functions work well with it. For example, pattern matching work exactly the same in recv as in function dispatch or case expressions.
On the other hand, the send, recv and spawn primitives in Gambit Scheme seems to work out really well even though the language is LISP in root (or maybe that's the reason?)
In fact, this is one of the few places where it would be harder to add something to JRuby than MRI. Since we can't control the full stack it would be very hard to implement anything resembling Erlang processes in Java. And Java threads would almost certainly be too heavy weight for this to work. Hmm.
Prenumerera på:
Kommentarer till inlägget (Atom)
7 kommentarer:
Scala already does it, why would it be so hard to do with JRuby?
How difficult would it be to make Ruby's green threads take advantage of multiple processors or multiple cores? As I understand it, all Ruby's threads run in a single process so they are never actually run in parallel, regardless of the number of cores in the machine on which it is being run.
A couple aspects of Erlang that makes it's concurrency model less error prone are immutable state and single assignment variables. You could leave it up to the programmer to enforce that in Ruby, which would be error prone, or enforce it in the language (in which case it would not really be Ruby anymore).
One option would be to create new interpreter instances (cf. "Sandbox") for every Actor.
Well, there are multiple things in play here, one being the thread/process model. You're right that the "1000's of processes" model probably doesn't work when those processes map 1-1 to o/s threads.
But ignoring that difficult issue for the moment, the other issue is coming up with the programming model for the message sending. My first reaction to see Erlang process message sends was that this is nothing more than a variant of the Actor model. Well, my view of the Actor model anyway. Which is; a process that has a queue; other processes can add stuff to the queue for the process to work on, but only the owning process can read from the queue. Erlang adds goodies like pattern matching of the messages, broken link notifications, etc. You can get a lot done with just the basics though. Someone needs to be looking at that in the Ruby space, if they haven't already.
@Patrick: MenTaL guY has his Omnibus Concurrency Library that adds Actor. Also, I believe that Rubinius also has an Actor implementation from MenTaL guY, but I don't know if it is the same implementation.
http://rubyforge.org/projects/concurrent/
http://rubini.us/
Would Stackless Python style concurrency be more or less difficult than Erlang style?
See this discussion for another challenge ... tail recursion.
http://www.nabble.com/Erlang-port-to-the-Java-Virtual-Machine-t1704124.html
Skicka en kommentar