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
