[coyotos-dev] Sleep, wakeup, and persistence

[Charles Landau]

At 2:30 PM +0200 9/15/07, Valerio Bellizzomi wrote:
>On 15/09/2007, at 11.34, Sam Mason wrote:
>  >It seems to me that the only sensible thing the kernel can do is the
>>first option, that of cancelling all sleeps upon restart.  If there's
>>a chance that the kernel isn't going to know the time when it restarts
>>then it can't do anything else.
>
>Yes, I agree that (1) seems to be the only sensible thing to do. If the
>system had a power loss, probably there is some alarm to service ASAP on
>restart, and you don't want you application to be sleeping at that time.

It does not follow that *all* sleeps should be cancelled. The program 
that needs to service the alarm needs to be woken up, but some other 
applications can continue to sleep blissfully. They need different 
interfaces.

At 11:34 AM +0100 9/15/07, Sam Mason wrote:
>If applications want to wait until a specific time, they will have
>needed to have got the current time from somewhere.  When their sleep is
>cancelled they can reacquire the current time and resume their sleep.

Sure they can. But do they want to? When a program asks the system to 
not run it until a specific (wall) time, the system should do that. 
Are you designing the system for the convenience of the applications, 
or the convenience of the system?

At 11:00 PM -0400 9/14/07, Jonathan S. Shapiro wrote:
>Whether there is one sleeping application or
>many actually does not change the required kernel interface.

You began this thread asking about the system design. Now it appears 
you are concerned about just the kernel interface. I won't comment on 
what should be done by the kernel versus user processes, because I 
don't know all the constraints of your kernel.

I still believe it is both desirable and possible for processes to 
not have to be aware of restart, unless they need to for semantic 
reasons.