[coyotos-dev] Sleep for interval

[Charles Landau]

At 12:33 PM -0400 9/30/07, Jonathan S. Shapiro wrote:
>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.

That is why I dislike non-blocking invocations.

>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.

There is a qualitative difference between an emulated invocation that 
blocks for a few milliseconds because the emulator is temporarily 
busy doing something else, and an emulated invocation that blocks 
process A for a week because it requested to wake up process B after 
a week. Neither is a precise emulation, but the former is most likely 
good enough, while the latter certainly isn't.

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

Easy: sleep the returnee instead of the invoker.
Perhaps what this means in Coyotos is "send a message to the reply 
endpoint after the specified time".