Re: Premature wakeup of time.sleep()



Erich Schreiber <gmane-esc@xxxxxx> wrote:
> In the Python Library Reference the explanation of the time.sleep()
> function reads amongst others:
>
> > The actual suspension time may be less than that requested because
> > any caught signal will terminate the sleep() following execution
> > of that signal's catching routine. Also, the suspension time may
> > be longer than requested by an arbitrary amount because of the
> > scheduling of other activity in the system.
>
> I don't understand the first part of this passage with the premature
> wakeup. What signals would that be?

If someone sent your process a signal. Say you pressed CTRL-C - that
generates the INT signal which python translates to the
KeyboardInterrupt exception - and which does interrupt the sleep()
system call.

This probably isn't happening to you though.

> In the logs I see a about 1% of the wake-up delays beeing negative
> from -1ms to about -20ms somewhat correlated with the duration of the
> sleep. 20 minute sleeps tend to wake-up earlier then sub-second
> sleeps. Can somebody explain this to me?

Sleep under linux has a granularity of the timer interrupt rate (known
as HZ or jiffies in linux-speak).

Typically this is 100 Hz, which is a granularity of 10ms. So I'd
expect your sleeps to be no more accurate than +/- 10ms. +/- 20ms
doesn't seem unreasonable either.

(Linux 2.4 was fond of 100Hz. Its more configurable in 2.6 so could be
1000 Hz. Its likely to be 100 Hz or less in a virtual private server.)

I'm not sure the best way of finding out your HZ, here is one (enter
it all on one line)

start=`grep timer /proc/interrupts | awk '{print $2}'`; sleep 1;
end=`grep timer /proc/interrupts | awk '{print $2}'`; echo $(($end-$start))

Which prints a number about 1000 on my 2.6 machine.

--
Nick Craig-Wood <nick@xxxxxxxxxxxxxx> -- http://www.craig-wood.com/nick
.



Relevant Pages

  • Re: Abolishing sleeps in issignal()
    ... mutex complicates sleep queues by forcing them to drop the spinlock to ... check for signals and then check for races. ... So SIGSTOP combined with a stopeventactually breaks because ... debugging events and SIGSTOP not aborting non-restartable syscalls as they ...
    (freebsd-arch)
  • Re: signal to a sleeping process...
    ... in the followin code ..parent forks and sleeps. ... No, signals are asynchronous, and can interrupt normal calls. ... kernel mode to user mode. ... hence according to it..the parent must sleep first and when its state ...
    (comp.unix.programmer)
  • Re: killing thread
    ... Even if I call pthread_cancel or deliver a SIGTERM signal with pthread_kill, the former thread continues to run and it exits only after timer expires. ... So do you really mean that it "continues to sleep", or do you mean that it wakes from the sleep but fails to TERMINATE as you expected? ... The process control signals are an integral part of POSIX/UNIX job control, and changing the semantics from process level to thread level would have broken a lot of things. ... Delivery of the signal, presuming the signal isn't blocked by the target, will interrupt any interruptable call. ...
    (comp.programming.threads)
  • Re: Problems on sleep/resume in XScale and PB 4.2
    ... enters in suspend sequency and when the code of the OEMPowerOff ... function is executed and the PXA255 enters in sleep mode, ... the rest of the signals that reach to the Flash and I am going to try ... like in the first lines of the reset handler in the fwxsc1.s file, ...
    (microsoft.public.windowsce.platbuilder)
  • Premature wakeup of time.sleep()
    ... > The actual suspension time may be less than that requested because ... > any caught signal will terminate the sleep() following execution ... My script sleeps for a random time and on waking ... In the logs I see a about 1% of the wake-up delays beeing negative ...
    (comp.lang.python)