Right. this is why it's tricky. You don't want to force an interrupt every microsecond just because sometimes people might be sleeping with that granularity (because it would be too often). But the delay is long enough that a busy-wait is also wrong. You need to dynamically change the clock behavior in response to the system calls.
On Mon, Aug 16, 2010 at 8:08 AM, Samuel Thibault <samuel.thiba...@gnu.org>wrote: > Da Zheng, le Mon 16 Aug 2010 06:02:17 -0400, a écrit : > > Should we still handle the special cases in mach_msg or in another system > call? > > > > While sleeping in microseconds or nanoseconds, the kernel should do the > loop on > > the behalf of the user process. Why do we still need a wakeup queue? > > You don't want to busy-loop for whole microseconds, but rather use a > hardware clock for that and get an interrupt when it's time to resume > the user process. > > Samuel > >
