[coyotos-dev] Sleep, wakeup, and persistence

[Valerio Bellizzomi]

On 22/09/2007, at 16.22, Jonathan S. Shapiro wrote:

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

Ok, but in this case the process must be awaken on restart.

>
>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
>
>_______________________________________________
>coyotos-dev mailing list
>coyotos-dev at smtp.coyotos.org
>http://www.coyotos.org/mailman/listinfo/coyotos-dev