[Openmcl-devel] sleep function in Cocoa.
Gary Byers
gb at clozure.com
Tue Dec 31 16:59:44 PST 2013
I can't reproduce this on a fairly recent version of the CCL trunk and
OSX 10.9.0; I haven't yet "upgraded" to 10.9.1. I find that (SLEEP 1) takes
very slightly more than 1 second; I've seen TIME claim that (SLEEP 10) takes
very slightly less than 10 seconds, but I assume that the small discrepancy
there has to do with slight differences between clock sources. I tried this
both running CCL in the shell and running under the Cocoa IDE; I got essentially
the same results in both cases and don't remember any recent CCL change that
would explain the results that you're seeing.
There's usually some latency involved: the calling thread can wake up after
having slept for the specified time interval, but it may be a little while
before the OS actually wakes it up. If there's a very heavy load on the system
(lots of other threads running) this latency will be higher than it would be
otherwise, but if system load was causing the results that you're seeing you'd
likely be very aware of that (everything would have slowed to a dead crawl.)
On Unix-based systems, SLEEP is implemented in terms of the #_nanosleep system
call; the OSX implementation of #_nanosleep has had a bug off and on since OSX
10.5, and (until around 2 years ago) CCL's attempts to work around that bug
sometimes made things worse. (If #_nanosleep is interrupted by a signal before
the timeout is reached, it's supposed to return a value indicating that that
had happened and optionally another value which indicated how much time
was remaining; on OSX, if #_nanosleep was interrupted after the scheduled
deadline, it claimed that it was interrupted and that a small negative
amount of time remained. The field in the data structure was unsigned,
so the "small negative remaining time" was interpreted as a very large
positive remaining time, and retrying the #_nanosleep effectively slept
forever.) I don't think that that's been present in the last few OSX
releases and I think that current versions of CCL work around it correctly.
So: it took me a while to say it, but I can't reproduce the problem and don't
have a good guess as to what it might be.
On Tue, 31 Dec 2013, Park SungMin wrote:
> in Mavericks(OS X 10.9)? I call sleep function..(in CCL IDE and slime(require ?cocoa))
> (sleep 1)? sometime sleep to over 10 seconds,?
> ?also, NSTimer sometime have long interval in repeats.
>
> so I tested it?. is it bug? Thanks.
>
>
> Welcome to Clozure Common Lisp Version 1.10-dev-r15993M-trunk (DarwinX8664)!
> ? (dotimes (i 5)
> (time (dotimes (i 100)
> (sleep 1))))
>
> (DOTIMES (I 100) (SLEEP 1))
> took 310,040,206 microseconds (310.040200 seconds) to run.
> During that period, and with 4 available CPU cores,
> 121,045 microseconds ( 0.121045 seconds) were spent in user mode
> 40,618 microseconds ( 0.040618 seconds) were spent in system mode
> 2,119 minor page faults, 3 major page faults, 0 swaps.
>
> (DOTIMES (I 100) (SLEEP 1))
> took 297,074,248 microseconds (297.074250 seconds) to run.
> During that period, and with 4 available CPU cores,
> 95,682 microseconds ( 0.095682 seconds) were spent in user mode
> 32,199 microseconds ( 0.032199 seconds) were spent in system mode
> 2,327 minor page faults, 6 major page faults, 0 swaps.
>
> (DOTIMES (I 100) (SLEEP 1))
> took 450,511,262 microseconds (450.511260 seconds) to run.
> During that period, and with 4 available CPU cores,
> 85,223 microseconds ( 0.085223 seconds) were spent in user mode
> 32,064 microseconds ( 0.032064 seconds) were spent in system mode
> 2,588 minor page faults, 9 major page faults, 0 swaps.
>
> (DOTIMES (I 100) (SLEEP 1))
> took 361,880,357 microseconds (361.880340 seconds) to run.
> During that period, and with 4 available CPU cores,
> 83,736 microseconds ( 0.083736 seconds) were spent in user mode
> 24,041 microseconds ( 0.024041 seconds) were spent in system mode
> 1,110 minor page faults, 4 major page faults, 0 swaps.
>
> (DOTIMES (I 100) (SLEEP 1))
> took 453,001,014 microseconds (453.001040 seconds) to run.
> During that period, and with 4 available CPU cores,
> 103,395 microseconds ( 0.103395 seconds) were spent in user mode
> 24,570 microseconds ( 0.024570 seconds) were spent in system mode
> 958 minor page faults, 1 major page faults, 0 swaps.
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
More information about the Openmcl-devel
mailing list