From: Josh E. <jo...@el...> - 2010-05-09 06:08:09
|
On Sun, May 09, 2010 at 06:58:54AM +0200, Thomas de Grivel wrote: > Josh Elsasser wrote: >> On Sun, May 09, 2010 at 04:14:48AM +0200, Thomas de Grivel wrote: >>> Thomas de Grivel wrote: >>>> This is a patch to fix the timer stress test unnecessarily failing >>>> due to very short timeout on OpenBSD/i386 (and maybe other >>>> platforms ?). >>>> >>>> I don't believe it changes any of the semantics of the test, and >>>> I'm sure it cannot break other systems. > >>> > >>> diff -ru tests/timer.impure.lisp.orig tests/timer.impure.lisp > >>> --- tests/timer.impure.lisp.orig Fri Apr 30 12:58:12 2010 > >>> +++ tests/timer.impure.lisp Fri May 7 16:02:34 2010 > >>> @@ -159,7 +159,7 @@ > >>> (let ((time (1+ (get-universal-time)))) > >>> (loop repeat 200 do > >>> (schedule-timer (make-timer (lambda ())) time :absolute-p > t)) > >>> - (sleep 2) > >>> + (sleep 5) > >>> (assert (zerop (length (sb-impl::%pqueue-contents > sb-impl::*schedule*)))))) > >>> > >>> (with-test (:name (:with-timeout :timeout)) > >> >>> Can anyone confirm this ? >> >> Yes, this test fails on any OpenBSD system regardless of >> architecture. I believe the correct fix here is to handle all pending >> timer events whenever SIGALRM is delivered, instead of one per signal. > > Do you mean that the above patch is wrong ? I don't really understand > the arbitrary value of 2 seconds sleep, what if the OS cannot process > these 200 scheduled calls in two seconds ? The OS isn't processing the scheduled calls, it's just delivering a signal after a period of time. You are right in that some OSes won't deliver that signal more than a certain number of times per second, which is why SBCL should try to handle more than one expired timer per signal. |