The current technique is to use a blocking mach_msg which will never complete, and with a timeout. The reason that nanosleep and usleep don't work is because 10ms is the granularity of the Mach clock. Changing the interface here isn't the issue so much as changing the implementation.
Thomas On Mon, Aug 9, 2010 at 2:22 PM, <olafbuddenha...@gmx.net> wrote: > Hi, > > On Tue, Jul 06, 2010 at 08:44:30AM +0800, Da Zheng wrote: > > > I need a program to sleep in several microseconds, but neither > > nanosleep() nor usleep() can work. They sleep at least 10ms. So it > > seems the only option is to use loop and Linux kernel does so as well > > for udelay() and ndelay(). Then I need high resolution timing. I think > > I can use TSC, but it's better to be system independent. There is > > clock_gettime() in POSIX, but surprisingly it's not implemented in > > glibc in Hurd. Any suggestions? > > For the record: I still think that the best solution would be a special > kernel call that does precise delays; automatically using delay loops > for short sleeps, or the best available timer for longer ones. This > stuff is pretty machine-specific, and thus -- at least in the Mach world > -- it's a job for the kernel. (Though even L4 does timer handling in the > kernel AIUI -- after all, the kernel needs some timer support itself, to > implement process scheduling...) > > Of course such a kernel call would still be a bit rough for really short > delays, because of the general kernel call overhead. I guess it would be > good enough for most applications though. > > -antrik- > >
