On May 27, 2006, at 7:50 AM, Francis Cianfrocca wrote:
> I come in for a lot of criticism because I don't care for the way many
> programmers are trained to use threads. But I think the  
> shortcomings of the
> typical approach to threaded programming that is encouraged by  
> languages
> like Ruby, Java and even Python will be far more deleterious on the  
> coming
> hardware than they are today. Ironically, Java may have an edge  
> because it
> has some deployment systems that can partition programs into
> indepedently-schedulable pieces. I'd like to see something similar  
> for Ruby
> (and have opened a project ("catamount") to do so) but it's still  
> early.

Have you investigated or played around with the concurrency model  
that Bertrand Meyer
has written about for Eiffel?  Last time I checked it wasn't  
implemented but it seemed
like an interesting abstraction.

I do agree with you that it takes a lot of discipline to use threads  
effectively.
Many times it seems like a standard multi-process model would work  
just as well as
trying to play with fire in a shared address space.  Unix used to be  
known for its
'cheap' processes and now everyone seems to think that process  
creation is monumentally
expensive.

The Plan 9 approach to the process/thread dichotomy is pretty  
interesting also.

Sometimes I think language design in the real world has been held  
back by the
limitations of the two generally available OS frameworks (Unix and  
Windows).


Gary Wright