From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2006-11-09T00:29:08+09:00
Subject: Re: Book wanted: Concurrent Ruby Programming (was Re: Book wanted: Metaprogramming in Ruby)

Ashley Moran wrote:
>
> 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
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.