Re: Failures in ‘threads.test’

[dsmich]

---- "Ludovic Courtès" <address@hidden> wrote: 
> Hi Dale,

Greetings.   Thanks for taking a look.  And for adding a Subject:  (oops!)


> An easy answer, but there’s some truth in it:
> 
> <address@hidden> writes:
> 
> > With guile at v2.0.0-134-g38c50a9, I'm getting a couple of failures in 
> > threads.test on my single core Debian Squeeze machine:
> >
> > FAIL: threads.test: lock-mutex: timed locking succeeds if mutex unlocked 
> > within timeout
> 
> This one may be sensitive to load.  Can you try changing
> (+ (current-time) 2) to (+ (current-time) 5)?

Still failing.  Ok I take that back.  There was two places with (+ 
(current-time) 2).  After changing the other one it is *not* failing.

diff --git a/test-suite/tests/threads.test b/test-suite/tests/threads.test
index 2ffffb5..ba0a2a1 100644
--- a/test-suite/tests/threads.test
+++ b/test-suite/tests/threads.test
@@ -213,7 +213,7 @@
                                          (signal-condition-variable c)
                                          (unlock-mutex cm)
                                          (lock-mutex m
-                                                     (+ (current-time) 2))))))
+                                                     (+ (current-time) 5))))))
              (lock-mutex m)
              (wait-condition-variable c cm)
              (unlock-mutex cm)


> > FAIL: threads.test: mutex-ownership: mutex with owner not retained (bug 
> > #27450)
> 
> This one is GC-sensitive.  It’s already kludged at length to improve the
> chances of success, but I don’t know how to improve the situation.  It
> could throw unresolved instead of failing, but that doesn’t really
> help...

This message I think I never see when running the test directly.  Only with 
"make check" do I see it.  Yeah, three times in a row with make check, never 
with ./check-guile threads.test.

I'm running 7.2alpha5 libgc.  From that tarball I think, not cvs.

-Dale