[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch for 0.6.0.20070501-2:frontpage_controller
From: |
Dmitry Borodaenko |
Subject: |
Re: patch for 0.6.0.20070501-2:frontpage_controller |
Date: |
Wed, 9 May 2007 23:43:15 +0100 |
On 5/8/07, Dmitry Borodaenko <address@hidden> wrote:
Yes, it seems to be more reliable now, but in a way, I was right about
the cache deadlock: there is a race condition there, and the more we
rely on cache, the more likely it is to occur. I've spend better part
of last weekend trying to get rid of it, but it's not that easy to do
that and in the same time to keep Cache#fetch_or_add re-enterable. The
deadlock point is the downgrade from global lock to entry lock in
fetch_or_add: if you release global lock before locking the entry, you
get cache corruption, other way around you get deadlock. Good news is
that I found a way to reproduce this bug more or less consistenly:
just run two functional tests (test/tc_robot.rb) in parallel. Bad news
is that I haven't yet found a way to resolve this, could use some help
here.
Good news: deadlock resolved, see CVS or wait for version
0.6.0.20070509-1 in Debian/experimental. Bad news: it won't work
unless you fix a bug in sync.rb from standard Ruby library (in
/usr/lib/ruby/1.8/ on Debian):
--- sync.rb.dpkg-dist 2007-05-08 23:35:15.000000000 +0100
+++ sync.rb 2007-05-09 01:04:37.000000000 +0100
@@ -54,6 +54,7 @@
# exceptions
class Err < StandardError
def Err.Fail(*opt)
+ Thread.critical = false
fail self, sprintf(self::Message, *opt)
end
@@ -129,10 +130,10 @@
# locking methods.
def sync_try_lock(mode = EX)
- return unlock if sync_mode == UN
+ return unlock if mode == UN
Thread.critical = true
- ret = sync_try_lock_sub(sync_mode)
+ ret = sync_try_lock_sub(mode)
Thread.critical = false
ret
end
This patch was submitted to ruby-core:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/11126
Until this is included upstream, or at least in the Debian package of
Ruby, we'll have to rely on people looking into README.Debian when
their samizdat-drb-server fails. Yet another reason to write a debconf
warning screen soon...
--
Dmitry Borodaenko