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 utilisation. 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? Cheers, Bob ---- Bob Hutchison -- blogs at <http://www.recursive.ca/ hutch/> Recursive Design Inc. -- <http://www.recursive.ca/> Raconteur -- <http://www.raconteur.info/> xampl for Ruby -- <http://rubyforge.org/projects/xampl/> _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
