[Mongrel] Mongrel spewing backtraces and nanosleeping

Kirk Haines wyhaines at gmail.com
Thu Sep 14 10:07:38 EDT 2006

I am wondering if this might arise because of a potential race
condition within Sync?  A 'Thread.critical = true' does not affect
threads that did not exist at the time that it was called, and the
lock() in Sync does quite a bit of work between when it declares a
critical area and when a thread either gets the lock or does not.

If a bunch of threads are killed very quickly, one of the remaining
threads will get into that thread critical section, but I think it may
be possible for a newly spawned thread to also get into there before
the other one finishes its work.

If that happens, and two threads think they have the lock, while Sync
thinks only one does, then when the one that does not have the lock
calls unlock, you get the error that you reported.

Jacob, I have attached a version of thread.rb that makes a slight
change to Mutex to avoid the memory management issues that the stock
one runs into with regard to Array.  It is otherwise identical to the
stock thread.rb.  I am curious if you replace your thread.rb with this
one, and flip Mongrel back to using Mutex, if you can still get this
same failure mode to happen?

Kirk Haines
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread.rb
Type: application/x-ruby
Size: 8406 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20060914/1195f96a/attachment.bin 

More information about the Mongrel-users mailing list