Timing bug?

[Matthew S. <mts...@gm...>]

Hi,

I've come across a strange performance problem with CLISP 2.49 while
working on a project today. I have the following function, simplified
from some code for doing IO with timeouts (is there a better way to do
this than polling?):

(defun poll-test ()
  (let ((deadline (+ (get-internal-real-time)
                          (* .5 internal-time-units-per-second))))
    (loop while (<= (get-internal-real-time) deadline)
       do (sleep 0.01))))

Most of the time the loop is never run, which is surprising (is there
really a .5 second lag between computing/storing the deadline value
and the first loop iteration?), but understandable. When the loop does
run, however, the function takes an awfully long time to complete
(real time), but uses relatively little cpu time:

CL-USER> (time (poll-test))
Real time: 46.03638 sec.
Run time: 0.27196 sec.
Space: 211992 Bytes

On a few occasions, I've even interrupted one of these tests at
300-400 seconds (real time, reported by the time form above), which
makes me fairly certain this isn't your normal garbage-collection
pause. An strace of the clisp process during one of these long runs
shows lots of select() calls, all of which timeout, with periodic
mmap()s. The long run behavior can be tricky to reproduce, and
combined with the extremely-short no-loop calls suggests this is some
sort of timing-related issue. I've traced the bytecode from
"(disassemble #'poll-test)" by hand and it looks solid, if that's of
any diagnostic use.

Is this a bug? Is my system (or code) broken? Is this just my
scheduler going crazy?

-Matt Stickney