aberrations in a scheduler loop
Hi,
I generally work with the professional edition of LWM on an Intel Mac.
Sometimes I test my code on a powerPC G5 (single processor 2 Ghz)
using the personal edition of LW. In this situation I encountered a
very strange problem and I can't understand if this problem is related
to the different hardware used or (maybe) to the heap size limitation
of the personal edition.
Simplified, my code (a scheduler loop) get the host clock time, do
something, sleep for ± one MSec, and retain the clock in a variable
for the next iteration.
After a lot of efforts to understand the strange things I observed, I
added this test in the loop :
IF the current clock is smaller than the previous clock
THEN print a list of the form (current previous)
And I was surprised to got these printouts (for a test of maybe two or
three minutes) :
(253954744459 256124475163)
(253954744459 256199840389)
(253954744459 256414704970)
(253954744459 257016437709)
(253954744459 257158069959)
(253954744459 257228130901)
(253954744459 257483039210)
(258249711755 258686301949)
(258249711755 258828856542)
(258249711755 258830737132)
(258249711755 258838794217)
(258249711755 259432733868)
(258249711755 259456775185)
(258249711755 260004755879)
where 'current' is actually smaller than 'previous' (witch is already
very strange...), and where 'current' is also always the same number
for some periods...
some clues :
- during one of these test, I got an error message signaling that I
reach the heap size limit of LWPE and after 2 or 3 seconds the
application quits.
- these aberrations have very variable density and seems to appear
only after some delay.
- with a sleep interval of 10ms the aberrations are less frequent but
still appear (I got the first after maybe 1 or 2 minutes)
- if the loop is encapsulated in a function an compiled, the
aberrations doesn't appear (at least for a reasonable observable
period). But this is for the simplified test version witch does
nothing, because in my codes (where the activity inside each iteration
is naturally much bigger) the scheduler is compiled and produces
aberrations anyway
I join the codes for this test below
An additionnal and optional question is : if this loop overflows the
heap, how is it possible while it really does nothing but getting a
clock from the host system ?
The test is based on a specific Mac API, but in any case, any ideas or
comments will be greatly appreciated
Thanks by advance
Denis
(in-package :cl-user)
(fli:register-module :System
:real-name "/System/Library/Frameworks/System.framework/System"
:connection-style :immediate)
(fli:define-c-typedef Uint64 (:unsigned :long :long))
(fli:define-c-typedef Uint32 (:unsigned :long))
(fli:define-c-typedef Sint32 (:signed :long))
(fli:define-c-struct mach_timebase_info
(num Uint32)
(den Uint32))
(fli:define-foreign-function (mach_timebase_info "mach_timebase_info")
((info (:ptr mach_timebase_info)))
:module :system
:result-type Sint32)
(fli:define-foreign-function (mach_wait_until "mach_wait_until") ((time UInt64))
:module :system
:result-type Sint32)
(fli:define-foreign-function (mach_absolute_time "mach_absolute_time") ()
:module :system
:result-type Uint64)
(defvar *timeMachRatio* (fli:with-dynamic-foreign-objects ((timeBase
mach_timebase_info))
(let ((result (mach_timebase_info
timeBase)))
(if (zerop result)
(/ (fli:foreign-slot-value timeBase
'num) (fli:foreign-slot-value timeBase 'den))
(error (format nil "mach_timebase_info
error ~d" result))))))
(defparameter *run* t)
#|
THE TEST :
(loop while *run*
with prev
with oneMSMach = (round 1000000 *timeMachRatio*) ;one ms in host
time ticks
for now = (mach_absolute_time) ;get the current host time
;the debbuging test
when (and prev (< now prev)) do (print (list now prev))
do
(mach_wait_until (+ now oneMSMach)) ;sleep for one ms
(setf prev now)) ;<==== evaluate to start the test
(setf *run* nil) ;<==== evaluate to stop the test
|#