From: Charles Oliver Nutter <charles.nutter@...>
Date: 2008-07-01T21:51:08+09:00
Subject: Re: Threads and Ruby

ara.t.howard wrote:
> 
> On Jun 30, 2008, at 6:55 PM, Charles Oliver Nutter wrote:
> 
>>
>> The fact that Ruby's threading has many breakages and pitfalls does 
>> not mean threading in general is the wrong way to fix things. Java 
>> threading works extremely well, with the only real requirement that 
>> you must either synchronize or avoid access to shared resources. 
>> Power...responsibility...etc. You can't damn threading because the 
>> standard implementation of Ruby doesn't do it well.
>>
>> Perhaps you're right that when you only have access to green threads 
>> that processes are the right way to go, since green threads don't 
>> really gain you anything other than simulated asynchrony. But native 
>> threads done right are as good as separate processes, with the bonus 
>> that you can share fast in-memory access to resources if you're 
>> willing to accept the synchronization cost and complexity.
> 
> yeah i agree 100% in principle.  however i was programming java when 
> stopping threads suddenly became depreciated, which i know you know all 
> about, but for others

The deprecation of thread stop, suspend, and exception raising was 
implemented precisely because of the shared resource requirements. If 
you can stop a thread in an environment where it may have been using 
resources other threads will use, it's impossible to know if those 
resources have been cleaned up or released safely. Sure, you can stop a 
process. The Java deprecations were done because it's provably 
impossible to share in-process resources and safely terminate threads at 
will.

The same goes for shared out-of-process resources, but since it's harder 
to share out-of-process resources it's harder to do serious damage. You 
can still corrupt files, orphan processes, or leave sibling processes 
waiting for data that will never arrive. You can even introduce exactly 
the same race conditions common to threading if you want multiple 
processes to perform atomic mutations of shared files or memory. If you 
have a large interconnected app with lots of processes communicating or 
using shared resources, arbitrarily nuking one of them can cause exactly 
the same headaches. It's a factor of resource sharing and 
interdependency, rather than anything specific to threading over processes.

> now having said that, i very often use ruby threads but often do so in a 
> message passing fashion and even more often use those threads to spawn 
> processes and achieve parallelism so i definitely am glad they are there 
> (Thread.new{ curl } is ultra powerful). still, i can't help but feel 
> they are destined to become relics - at least in the direct fashion we 
> use them now.

Probably not, but hopefully neither will typical IPC mechanisms, which 
are almost as painful to get right and make reliable. Threads are a 
low-level API, perhaps lower-level than day-to-day programmers should 
generally have to deal with. 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. Threads have a place, 
though the ease in which resources can be shared often makes it a 
dangerous place to go. Let's not throw the threading baby out with the 
shared resource bathwater.

- Charlie