Re: Failures in ‘threads.test’

[<dsmich@roadrunner.com>]

---- "Ludovic Courtès" <ludo@gnu.org> 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:
> 
> <dsmich@roadrunner.com> 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