From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <0263c93c2d57900638e664f1b538a76d@brasstown.quanstro.net> References: <0263c93c2d57900638e664f1b538a76d@brasstown.quanstro.net> Date: Wed, 28 Nov 2012 13:10:57 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] sleep(2) historical question Topicbox-Message-UUID: eaf956a8-ead7-11e9-9d60-3106f5b1d025 No, really, I'm quite serious. A grep of /sys/src/cmd/ suggests that most sleeps are relatively large, and arbitrary. None of the applications look likely to need microsecond let alone nanosecond resolution, and that seems reasonable to me. One exception is sleep(0), but that's yield() If I want tight timing, I'll switch to a real-time discipline, including scheduling. On 28 November 2012 12:57, erik quanstrom wrote: > On Wed Nov 28 02:38:39 EST 2012, charles.forsyth@gmail.com wrote: >> the relative unimportance of sleep? >> >> On 27 November 2012 23:19, erik quanstrom wrote: >> > why is sleep(2) limited in resolution to HZ in the >> > portable code? the underlying mechanism is often >> > much finer grained than HZ, and if there is a limit, >> > one would think that it's related to the hardware >> > mechanism, not the HZ clock. i'm clearly missing >> > something. > > that's not helpful. > > - erik >