[coyotos-dev] Sleep for interval

[Jonathan S. Shapiro]

On Tue, 2007-09-25 at 11:43 -0700, Charles Landau wrote:
> >In contrast to all other kernel capabilities, which are always
> >receiving, the definition of the sleep object is that it will remain in
> >a non-receiving state until the invoker's specified interval has run
> >out. This has three consequences:
> >
> >   1. Sleep always happens to the invoker. Process A cannot place process
> >      B onto a kernel sleep queue.
> 
> So the sleep object cannot be accurately proxied, which is 
> unfortunate. If you later did decide to implement this outside the 
> kernel, you could not do so compatibly.

Hmm. This is technically true, but I think that it may not matter.

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.

So the observability of the difference is really an artifact of
scheduling. I think that this is not very significant, but perhaps I am
missing something and Charlie can explain it.

> At 1:57 PM -0700 9/14/07, Charles Landau wrote:
> >Another notion is system-up time. I can say "sleep until the
> >system has run for at least 5 seconds". This might be useful for
> >timeouts of other programs.
> 
> This request might be difficult to fulfill if it is not supported in 
> the kernel.
> 
> I'm suggesting you give the sleeper the choice of (1) waking up after 
> x seconds of uptime, or (2) waking up after x seconds or restart 
> whichever occurs first. Note that uptime gets rolled back on a 
> restart.

The "sleep until uptime exceeds X" case does not need to be implemented
by the kernel. It can be implemented by a user-mode agent if the kernel
will disclose the start tick value.

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.

shap