On Jul 1, 2008, at 6:51 AM, Charles Oliver Nutter wrote:

> The Java deprecations were done because it's provably impossible to  
> share in-process resources and safely terminate threads at will.

<snip>

i think java is correct to have done so, precisely because people have  
found it too hard to write safe code using those mechanisms but as you  
point out, you can do the same with processes while no OS has limited  
us yet.  why?  i think it's because sharing data between threads, or  
processes, is both dangerous and powerful.  when someone builds an OS  
that supports message passing we'll see those operations limited on a  
processes too i bet but, for now, they are just too useful despite the  
danger and do work 'much' of the time which, for better or worse,  
seems to be the MO for many programming tasks.


>
> Probably not, but hopefully neither will typical IPC mechanisms,  
> which are almost as painful to get right and make reliable.

in fairness we're talking about ruby here where that is definitely not  
true.  it's extremely painless to have reliable ipc with ruby using  
drb or com with sqlite as a message store.


> . But it's absurd to say that processes can do everything threads  
> can, otherwise we'd have a massive process bloat for almost every  
> nontrivial applications we use.


for the record i'm not saying that - i'm saying that processes are a  
better starting point for most people wanting to gain parallelism in  
ruby for most problems.  threads are appropriate at times too but, in  
ruby, the disadvantages like lack of cpu migration, blocking the  
entire process (in win), etc limit their usefulness - jruby excepted  
of course (no jab, it's a huge advantage jruby has over the mri)

kind regards.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama