bug#12248: sleep is not arware of suspend mode

[Bob Proulx]

Paul Eggert wrote:
> Bob Proulx wrote:
> > That is the expected behavior.
> 
> It's not the behavior *I* expect.  I expect
> 'sleep' to use realtime seconds, not seconds
> of some arbitrary clock that's way far from
> real time.

Sleep has always been a pause in relative time from when the call is
made to when it returns.  Implementations have varied (signals,
select, etc.) each with various issues causing a move from one to the
other method.  But if the system suspends then all processes suspend
together.  When the system wakes up then all processes proceed
together from the point where they left off when suspending.  I think
anything else is going to create a lot of problems.

I could see a big problem for many processes on the system if when the
system resumes from suspend that all of the sleeping processes "all go
off at once".  It would cause a huge spike in system load as all of
them fired all at one time.  Granted that most sleeping processes are
going to be sleeping in C code and no change to the coreutils sleep
program will affect them.  But any scripts that are using sleep would
be affected.

Also, the reason for sleep is often to add skew between two events.
If upon wakeup all of the sleeping processes are all triggered then
all relative skew will have been removed.  Worse the wakeup would act
as a synchronization point causing all of the sleeping processes to be
deskewed.

But I can definitely see that sleeping until a particular time would
be useful behavior.  But that would be such as large expansion of code
and behavior that I think it should warrant a different program rather
than expand sleep that much.

Should we create a new command that sleeps until a particular system
time?

  sleepuntil --date="now + 30 minutes"

Bob