Ola B. wrote:
Ruby Wish List
resident expert, I think …
But concurrency in Ruby is still green threads, so that would have to
be either concurrency with YARV, or concurrency with separate Ruby
processes communicating in some way.
That was actually my purpose in making the suggestion … to stimulate
debate about concurrency in Ruby, the major differences between the
current 1.8 and proposed 1.9/2.0 concurrency tools, the way other
languages deal, successfully or unsuccessfully, with concurrency, etc.,
etc., etc. 
I think Erlang is the horse to challenge in this race, or perhaps, on a
more theoretical note, the Pi-calculus. And right now, EventMachine
appears to be Ruby’s horse in the race, which is why I suggested that
Francis write the book.
On a related note, some Scheme folks have implemented “Erlang-like”
lightweight processes. Here’s a link to the paper; I’ve got the software
installed but haven’t had a chance to experiment with it.
http://scheme2006.cs.uchicago.edu/09-germain.pdf
M. Edward (Ed) Borasky wrote:
On a related note, some Scheme folks have implemented “Erlang-like”
lightweight processes. Here’s a link to the paper; I’ve got the software
installed but haven’t had a chance to experiment with it.
Gambit Scheme is wicked. Incredibly cool. Lisp + Erlangs concurrency
features. Great.
If “easier” syntax is needed, Scala has some very interesting parts too.
–
Ola B. (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)
“Yields falsehood when quined” yields falsehood when quined.
On 7 Nov 2006, at 15:34, M. Edward (Ed) Borasky wrote:
That was actually my purpose in making the suggestion … to stimulate
debate about concurrency in Ruby, the major differences between the
current 1.8 and proposed 1.9/2.0 concurrency tools, the way other
languages deal, successfully or unsuccessfully, with concurrency,
etc.,
etc., etc.
I read this a while ago - I have a feeling the link came from this
list so you might be aware of it already.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html
Ashley
Ashley M. wrote:
I read this a while ago - I have a feeling the link came from this
list so you might be aware of it already.
The Problem with Threads | EECS at UC Berkeley
Ashley
Yes … there was some discussion a while back on that. Despite the fact
that threads have their problems, they aren’t going away. Neither are
sockets, lightweight processes, System V IPC, Linda/Rinda, CSP, CCS, the
Pi calculus, Petri nets, mutexes, monitors, the ACID properties for
database transactions, multi-core processors, or any of the other
reasons why a programming language needs to support concurrency and
tools for that support.
Some of these may die out, of course, through the natural competitive
process. For example, I hadn’t heard much about the Linda approach until
Ruby “re-discovered” it. There’s a “raging battle” in the business
processing modeling world between Petri nets and the Pi calculus, and as
a result both are fairly well supported and will be around for a while.
And I haven’t heard a lot recently about System V IPC; apparently Linus
Torvalds doesn’t like the constructs, so they were grudgingly put into
the Linux kernel for the same reason people that have issues with
threads implement them anyhow.
I have my personal favorites, of course. I’m a big fan of lightweight
processes as implemented in Erlang and Gambit Scheme/Termite. I’m a big
fan of Petri nets because they carry along with them not only mechanisms
for analysis of concurrent program correctness but also performance and
other timing-related factors. I expect the theoreticians will eventually
get around to providing the same performance modeling constructs in the
Pi calculus, but I haven’t seen anything yet.