[coyotos-dev] Sleep, wakeup, and persistence
Jonathan S. Shapiro
shap at eros-os.com
Sat Sep 22 16:22:23 EDT 2007
It will be obvious to everyone that I made a mistake, asking my question
just before we encountered a big push. I am now caught up.
What emerges in this thread is that there was a nearly complete
misunderstanding of what I was asking -- which is entirely my fault. I
did not intend to consider the question of wall clock time at all. This
led Charlie to some frustration, because he apparently thought that I
was talking about implementing wall-clock time (and presumably time
sonze and other gorp) within the kernel.
I want to respond to one thing that Charlie wrote.
First, let's consider the case where a system has access to a wall clock
[or equivalently an external time source]. Charlie has proposed that
such a system might want two distinct sleep interfaces:
> Interface 1: sleep untill a given wall clock time
>
> Interface 2: sleep until a given wall clock time or system restart,
> whichever occurs sooner
Offhand, I don't think that this serves a purpose. If a process has
specified a sleep in wall clock terms, it is waiting for a wall clock
event. In a checkpointing system, the description above cannot be
achieved. The best that can be achieved is:
Wake me up as soon as possible after a given wall clock time.
If the system is down when that time arrives, the wakeup will obviously
be deferred. A process with access to a wall clock can detect this
without need for an additional interface.
Conversely, if the system goes down but has been restored before the
deadline, then the deadline has not arrived and the process should not
be woken up.
What I am saying is that I think sleeps w.r.t. wall clock times should
not expose the checkpoint system.
However, just to be clear: the kernel will have no knowledge of wall
clock time. There will be an out-of-kernel object that has this
knowledge -- or at least there *may* be, depending on the system
configuration.
--
Jonathan S. Shapiro
Managing Director
The EROS Group, LLC
www.coyotos.org, www.eros-os.org
More information about the coyotos-dev
mailing list