Hi,
On Mon, Aug 16, 2010 at 05:07:02PM +0200, Samuel Thibault wrote:
> olafbuddenha...@gmx.net, le Fri 13 Aug 2010 08:42:33 +0200, a écrit :
> > I think improving the timeout granularity in general would be rather
> > complicated, and make little sense...
>
> Improving the timeout granularity fo
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
behavi
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?
olafbuddenha...@gmx.net, le Fri 13 Aug 2010 08:42:33 +0200, a écrit :
> I think improving the timeout granularity in general would be rather
> complicated, and make little sense...
Improving the timeout granularity for even just one case is most of the
work: programming e.g. the HPET timer, managi
Hi,
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?
Best,
Zheng Da
On 8/13/10 5:28 PM, Thomas Bushnell, BSG wrote:
Special casing is what I had in mind, but it's very tricky. The normal
wakeup-queue method is simply not adequate.
On Thu, Aug 12, 2010 at 11:42 PM, wrote:
> Hi,
>
> On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote:
>
> > The current technique is to use a blocking mach_msg wh
Hi,
On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote:
> 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.
Yeah, we figure
Thomas Bushnell, BSG, le Wed 11 Aug 2010 10:03:31 -0700, a écrit :
> 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 h
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 M
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().
10 matches
Mail list logo
