[Mongrel] [ANN] Mongrel Pre-Release -- Ruby's LEAK Fixed (Death To Mutex!)

Bob Hutchison hutch at recursive.ca
Sun Aug 27 10:16:41 EDT 2006

On Aug 26, 2006, at 6:02 PM, Zed Shaw wrote:

> On Sat, 2006-08-26 at 11:20 -0400, Bob Hutchison wrote:
>> On Aug 26, 2006, at 10:22 AM, Bob Hutchison wrote:
>> Well I tried your test on OS X. The Sync had no problem, the mutex
>> showed the memory growth (though it eventually (fifth iteration I
>> think) cleaned itself up). I modified your test to create exactly
>> 1000 threads and call GC three times at the end, things were better,
>> i.e. it released its memory more quickly than without, but still not
>> good. I ended up with:
> Thanks Bob, but I've gotta say this one more time, this test is not
> about 1000 threads.  The test is about how *Mongrel* processes  
> threads,
> a specific bug when many threads are put into a ThreadGroup and wait
> behind a Mutex, and how to stop that from leaking.

I know it isn't about 1000 threads, but when testing it *really*  
helps sometimes to lock as much down as possible. I was getting  
anywhere from 1005 through 1040 threads and that variation was too  
much. I like having exactly *one* thing vary between tests.

No matter. I posted on the ruby-talk list the result of some mucking  
about I was doing this morning. It seems that on OS X at least, the  
Mutex is holding threads in memory. If you delete the reference to  
the Mutex and then garbage collect you get a nice stable memory  

I have no idea if you can make use of this information. Is there some  
point at which you know you can clobber the Mutex in Mongrel?


Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>

More information about the Mongrel-users mailing list