[coyotos-dev] Sleep for interval

[Jonathan S. Shapiro]

On Fri, 2007-09-28 at 13:56 -0700, Charles Landau wrote:
> >The difference in behavior is this:
> >
> >   1. In the kernel case, the invoker appears blocked attempting to
> >      invoke.
> >   2. In the emulator case, the invoker succeeds, but then remains
> >      in the receiving state until the response.
> 
> I think it's worse. If you will allow me to describe the scenario in 
> KeyKOS/CapROS terms, since I may not be current on the latest 
> iteration of Coyotos IPC:
> 
> Process A forks the sleep capability, passing as the last key 
> parameter a resume key to Process B. In the kernel case, A blocks...

Hmm. So first: I do see the problem. Second: I don't consider this to be
a significant emulation failure, because there is *never* any guarantee
about the availability latency of an emulator.

But your example does prompt me to notice a much more general failing of
emulation. The kernel contract is that a kernel always appears to be
available. This implies that a non-blocking message sent to the kernel
will not block for reason of unavailability. Unfortunately, the same is
not true of a non-blocking send that goes to an emulator.

But in both cases (yours and mine), I think that what we have here is a
failure to emulate something that is outside the contract. In general,
NO send to a service should not rely on the service being available at
all times.

I do not believe that any emulation can be truly air-tight. To the
extent that precise emulation requires supporting corner cases that
really cannot be emulated correctly, precise emulation shouldn't be a
goal. I would cite latency as one example of something that cannot be
emulated in air-tight fashion.

Be that as it may, the issue at hand is the sleep interface. What would
you propose as a better interface here?

> >
> >I am certainly not opposed to this function. In fact, I think it's a
> >good idea. I just don't see that the kernel needs to implement it
> >directly.
> 
> I'm not sure what the "start tick value" is (I thought you started at 
> zero)...

At the moment, we start at zero relative to the current epoch, so "start
tick" is always zero.
-- 
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org