X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=tests%2Ftimer.impure.lisp;h=21ec58f8b8878976b5f07a0dc2d404916e4337f6;hb=367316f5f21281204393853910848fea7fb9a6ab;hp=29d2fbd8bbd06a1b779cb9a9e87f1402e444d873;hpb=23953bc6b14c93f59268996554c18706c8e16581;p=sbcl.git diff --git a/tests/timer.impure.lisp b/tests/timer.impure.lisp index 29d2fbd..21ec58f 100644 --- a/tests/timer.impure.lisp +++ b/tests/timer.impure.lisp @@ -184,10 +184,21 @@ (sb-ext:schedule-timer ticker 0 :repeat-interval 0.00001) thread))))))) -;;;; OS X doesn't like these being at all, and gives us a SIGSEGV -;;;; instead of using the Mach expection system! Our or OS X's fault? -;;;; :/ - +;;;; FIXME: OS X 10.4 doesn't like these being at all, and gives us a SIGSEGV +;;;; instead of using the Mach expection system! 10.5 on the other tends to +;;;; lose() where with interrupt already pending. :/ +;;;; +;;;; FIXME: This test also occasionally hangs on Linux/x86-64 at least. The +;;;; common feature is one thread in gc_stop_the_world, and another trying to +;;;; signal_interrupt_thread, but both (apparently) getting EAGAIN repeatedly. +;;;; Exactly how or why this is happening remains under investigation -- but +;;;; it seems plausible that the fast timers simply fill up the interrupt +;;;; queue completely. (On some occasions the process unwedges itself after +;;;; a few minutes, but not always.) +;;;; +;;;; FIXME: Another failure mode on Linux: recursive entries to +;;;; RUN-EXPIRED-TIMERS blowing the stack. +#+nil (with-test (:name (:timer :schedule-stress)) (flet ((test () (let* ((slow-timers (loop for i from 1 upto 100 @@ -228,5 +239,4 @@ do (sb-ext:schedule-timer (make-timer #'one :thread thread) 0.001)))))) (dolist (thread threads) (sched thread))) - (with-timeout (truncate goal 100) - (mapcar #'sb-thread:join-thread threads)))))) + (mapcar #'sb-thread:join-thread threads)))))