[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: deadlock in ThreadPool using backtick
From:       Charles Oliver Nutter <charles.nutter () sun ! com>
Date:       2007-12-31 23:44:56
Message-ID: 47797ED1.5010008 () sun ! com
[Download RAW message or body]

ara.t.howard wrote:
> 
> On Dec 31, 2007, at 1:59 PM, Charles Oliver Nutter wrote:
> 
>>
>> Isn't this largely just working around a lack of concurrency in Ruby's 
>> threading model (or perhaps a bug in backtick handling)? With 
>> concurrent threads I can implement the same thing in a trivial amount 
>> of code and not have to worry about backticks et al blocking, nor 
>> about spinning up processes. In fact with native threads the original 
>> ThreadPool from Ruby Cookbook ought to work fine for basically 
>> anything you want to throw at it (including backticks).
>>
>> Perhaps backtick needs to be fixed in MRI so it doesn't block the 
>> entire runtime?
> 
> in general you may be correct - but i think the OP's code has a race 
> condition.  if you look at the stacktrace it's not reading stdout 
> (backticks) that's got everyone's undies in a wedgie - it's the shutdown 
> method.  so basically the original code starts out by firing off a bunch 
> of threads, limited at the number 2.  let's assume it safely got two 
> running, but that none of have completed, that leaves every other thread 
> blocked here

Yes, what you pointed out is completely busted. I hadn't seen that code. 
But why would you spin things off into a bunch of processes? Just fixing 
shutdown should make it work fine, if backticks aren't the problem.

- Charlie

[prev in list] [next in list] [prev in thread] [next in thread]