<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">This is what I see on my 2012 Macbook Air with Mac OS X 10.9.1. iTunes was running in the background. Most of the time CCL was not the front application and its windows were hidden behind Apple Mail.<div><br></div><div><br></div><div><div>Welcome to Clozure Common Lisp Version 1.8-store-r15418 (DarwinX8664)!</div><div>? (dotimes (i 5)</div><div>(time (dotimes (i 100)</div><div> (sleep 1))))</div><div>(DOTIMES (I 100) (SLEEP 1))</div><div>took 100,110,658 microseconds (100.110660 seconds) to run.</div><div>During that period, and with 4 available CPU cores,</div><div> 149,869 microseconds ( 0.149869 seconds) were spent in user mode</div><div> 48,910 microseconds ( 0.048910 seconds) were spent in system mode</div><div> 1,066 minor page faults, 5 major page faults, 0 swaps.</div><div>(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>130,075,484</b> microseconds (130.075490 seconds) to run.</div><div>During that period, and with 4 available CPU cores,</div><div> 67,339 microseconds ( 0.067339 seconds) were spent in user mode</div><div> 32,443 microseconds ( 0.032443 seconds) were spent in system mode</div><div> 1,335 minor page faults, 3 major page faults, 0 swaps.</div><div>(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>131,043,588 </b>microseconds (131.043580 seconds) to run.</div><div>During that period, and with 4 available CPU cores,</div><div> 76,666 microseconds ( 0.076666 seconds) were spent in user mode</div><div> 32,517 microseconds ( 0.032517 seconds) were spent in system mode</div><div> 1,076 minor page faults, 3 major page faults, 0 swaps.</div><div>(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>137,310,368</b> microseconds (137.310360 seconds) to run.</div><div>During that period, and with 4 available CPU cores,</div><div> 109,781 microseconds ( 0.109781 seconds) were spent in user mode</div><div> 40,377 microseconds ( 0.040377 seconds) were spent in system mode</div><div> 588 minor page faults, 3 major page faults, 0 swaps.</div><div>(DOTIMES (I 100) (SLEEP 1))</div><div>took 100,122,436 microseconds (100.122430 seconds) to run.</div><div>During that period, and with 4 available CPU cores,</div><div> 93,868 microseconds ( 0.093868 seconds) were spent in user mode</div><div> 36,627 microseconds ( 0.036627 seconds) were spent in system mode</div><div> 577 minor page faults, 3 major page faults, 0 swaps.</div><div>NIL</div><div><br></div><div><br></div><div><br></div><div><div>Am 01.01.2014 um 01:59 schrieb Gary Byers <<a href="mailto:gb@clozure.com">gb@clozure.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">I can't reproduce this on a fairly recent version of the CCL trunk and<br>OSX 10.9.0; I haven't yet "upgraded" to 10.9.1. I find that (SLEEP 1) takes<br>very slightly more than 1 second; I've seen TIME claim that (SLEEP 10) takes<br>very slightly less than 10 seconds, but I assume that the small discrepancy<br>there has to do with slight differences between clock sources. I tried this<br>both running CCL in the shell and running under the Cocoa IDE; I got essentially<br>the same results in both cases and don't remember any recent CCL change that<br>would explain the results that you're seeing.<br><br>There's usually some latency involved: the calling thread can wake up after<br>having slept for the specified time interval, but it may be a little while<br>before the OS actually wakes it up. If there's a very heavy load on the system<br>(lots of other threads running) this latency will be higher than it would be<br>otherwise, but if system load was causing the results that you're seeing you'd<br>likely be very aware of that (everything would have slowed to a dead crawl.)<br><br>On Unix-based systems, SLEEP is implemented in terms of the #_nanosleep system<br>call; the OSX implementation of #_nanosleep has had a bug off and on since OSX<br>10.5, and (until around 2 years ago) CCL's attempts to work around that bug<br>sometimes made things worse. (If #_nanosleep is interrupted by a signal before<br>the timeout is reached, it's supposed to return a value indicating that that<br>had happened and optionally another value which indicated how much time was remaining; on OSX, if #_nanosleep was interrupted after the scheduled<br>deadline, it claimed that it was interrupted and that a small negative<br>amount of time remained. The field in the data structure was unsigned,<br>so the "small negative remaining time" was interpreted as a very large<br>positive remaining time, and retrying the #_nanosleep effectively slept<br>forever.) I don't think that that's been present in the last few OSX<br>releases and I think that current versions of CCL work around it correctly.<br><br>So: it took me a while to say it, but I can't reproduce the problem and don't<br>have a good guess as to what it might be.<br><br><br><br>On Tue, 31 Dec 2013, Park SungMin wrote:<br><br><blockquote type="cite">in Mavericks(OS X 10.9)? I call sleep function..(in CCL IDE and slime(require ?cocoa))<br>(sleep 1)? sometime sleep to over 10 seconds,?<br>?also, NSTimer sometime have long interval in repeats.<br><br>so I tested it?. is it bug? Thanks.<br><br><br>Welcome to Clozure Common Lisp Version 1.10-dev-r15993M-trunk (DarwinX8664)!<br>? (dotimes (i 5)<br>(time (dotimes (i 100)<br> (sleep 1))))<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 310,040,206 microseconds (310.040200 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 121,045 microseconds ( 0.121045 seconds) were spent in user mode<br> 40,618 microseconds ( 0.040618 seconds) were spent in system mode<br>2,119 minor page faults, 3 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 297,074,248 microseconds (297.074250 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 95,682 microseconds ( 0.095682 seconds) were spent in user mode<br> 32,199 microseconds ( 0.032199 seconds) were spent in system mode<br>2,327 minor page faults, 6 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 450,511,262 microseconds (450.511260 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 85,223 microseconds ( 0.085223 seconds) were spent in user mode<br> 32,064 microseconds ( 0.032064 seconds) were spent in system mode<br>2,588 minor page faults, 9 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 361,880,357 microseconds (361.880340 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 83,736 microseconds ( 0.083736 seconds) were spent in user mode<br> 24,041 microseconds ( 0.024041 seconds) were spent in system mode<br>1,110 minor page faults, 4 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 453,001,014 microseconds (453.001040 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 103,395 microseconds ( 0.103395 seconds) were spent in user mode<br> 24,570 microseconds ( 0.024570 seconds) were spent in system mode<br>958 minor page faults, 1 major page faults, 0 swaps.<br><br><br><br>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br><br><br></blockquote>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote></div><br></div></body></html>