Update of /cvsroot/sbcl/sbcl/src/code
In directory sfp-cvsdas-3.v30.ch3.sourceforge.com:/tmp/cvs-serv31028/src/code
18.104.22.168: less pain for building threads on Darwin
* Use RUN-PROGRAM for impure tests everywhere. Not only is it better
to use the more-portable solution everywhere, we had a huge number
of bogus failures on thread tests on Darwin due to interactions
between fork() and thread stack cleanup.
Addresses Launchpad bug #310208.
* Make tests depending on mutex timeout punt on lutex platform, and
make several test which are prone hang or crash into LDB punt on
Darwin. ("Punt" here means "call ERROR" so we get a test failure.)
* Disable mailbox tests prone to hang on Darwin.
...so building threads on Darwin means one actually has a prayer or
running the tests with useful results -- and the failures are real
RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -d -r1.132 -r1.133
--- target-thread.lisp 3 Apr 2010 19:56:28 -0000 1.132
+++ target-thread.lisp 7 Apr 2010 11:59:00 -0000 1.133
@@ -361,8 +361,7 @@
"Deprecated in favor of GRAB-MUTEX."
(declare (type mutex mutex) (optimize (speed 3))
- #!-sb-thread (ignore waitp timeout)
- #!+sb-lutex (ignore timeout))
+ #!-sb-thread (ignore waitp timeout))
(setq new-owner *current-thread*))
(let ((old (mutex-%owner mutex)))
@@ -385,12 +384,15 @@
;; but has that been checked?) (2) after the lutex call, but
;; before setting the mutex owner.
- (when (zerop (with-lutex-address (lutex (mutex-lutex mutex))
- (if waitp
- (with-interrupts (%lutex-lock lutex))
- (%lutex-trylock lutex))))
- (setf (mutex-%owner mutex) new-owner)
+ (when timeout
+ (error "Mutex timeouts not supported on this platform."))
+ (when (zerop (with-lutex-address (lutex (mutex-lutex mutex))
+ (if waitp
+ (with-interrupts (%lutex-lock lutex))
+ (%lutex-trylock lutex))))
+ (setf (mutex-%owner mutex) new-owner)
;; This is a direct translation of the Mutex 2 algorithm from
;; "Futexes are Tricky" by Ulrich Drepper.
@@ -444,7 +446,8 @@
If TIMEOUT is given, it specifies a relative timeout, in seconds, on
how long GRAB-MUTEX should try to acquire the lock in the contested
+case. Unsupported on :SB-LUTEX platforms (eg. Darwin), where a non-NIL
+TIMEOUT signals an error.
If GRAB-MUTEX returns T, the lock acquisition was successful. In case
of WAITP being NIL, or an expired TIMEOUT, GRAB-MUTEX may also return
@@ -468,9 +471,6 @@
ALLOW-WITH-INTERRUPTS allows the call to be interrupted from
- - The TIMEOUT parameter is currently only supported on non-SB-LUTEX
- platforms like Linux or BSD.
- (GRAB-MUTEX <mutex> :timeout 0.0) differs from
(GRAB-MUTEX <mutex> :waitp nil) in that the former may signal a
DEADLINE-TIMEOUT if the global deadline was due already on