Re: next... :)

[Jason L Tibbitts III <tibbs @ hpc . uh . edu>]

>>>>> "BF" == Bryan Fullerton <bryanf@samurai.com> writes:

BF> looks to me like it's doing an exclusive lock on _config, then not
BF> unlocking it before trying to do a shared lock on the same file.
BF> Unless there's an implied unlock somewhere?

You're essentially correct; the problem is that the Mj::Config::lock
implicitly loads/reloads the file if necessary, but neglects to note that
it has loaded the file.  Then when the first variable fetch comes along
(which happens to be inside the critical section) the get routine sees that
the file isn't yet loaded and so loads it.  This tries to acquire another
lock and hangs.

Try this (yes, one stupid line):

Index: lib/Mj/Config.pm
diff -u -r1.5 Config.pm
--- Config.pm   1998/04/12 07:35:51     1.5
+++ Config.pm   1998/04/29 23:04:52
@@ -721,6 +721,7 @@
   if ($self->{mtime} < (stat($name))[9]) {
     delete $self->{data};
     $self->{data} = do $name;
+    $self->{loaded} = 1;
   }
   
   # Note that we are locked

Good catch, BTW.

 - J<