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, <[email protected]
> <mailto:[email protected]>> 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 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 figured that out...
> 
>     > Changing the interface here isn't the issue so much as changing the
>     > implementation.
> 
>     You mean changing the way message timeouts are handled in general? Or
>     special-casing the specific situation?...
> 
>     I think improving the timeout granularity in general would be rather
>     complicated, and make little sense... I can't say anything about
>     special-casing -- don't know the details of this mechanism.
> 
>     -antrik-
> 
> 


Reply via email to