Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #73356 > unrolled thread

Under what kind of situation, time.sleep(n) would sleep much longer than n seconds?

Back to article view | Back to comp.lang.python

Contents

  Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? crow <wentlv@gmail.com> - 2014-06-18 02:52 -0700
    Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Marko Rauhamaa <marko@pacujo.net> - 2014-06-18 13:30 +0300
    Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-18 20:34 +1000
      Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? crow <wentlv@gmail.com> - 2014-06-18 08:24 -0700
        Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-19 09:38 +1000
          Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? crow <wentlv@gmail.com> - 2014-06-18 18:41 -0700
            Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-19 13:58 +1000
          Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Christian Gollwitzer <auriocus@gmx.de> - 2014-06-19 09:18 +0200
            Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-19 17:42 +1000
              Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Marko Rauhamaa <marko@pacujo.net> - 2014-06-19 12:20 +0300
              Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Christian Gollwitzer <auriocus@gmx.de> - 2014-06-19 19:17 +0200
                Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-20 08:57 +1000
            Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Terry Reedy <tjreedy@udel.edu> - 2014-06-19 22:33 -0400
            Re: Under what kind of situation, time.sleep(n) would sleep much longer than n seconds? Chris Angelico <rosuav@gmail.com> - 2014-06-20 12:54 +1000

#73356 — Under what kind of situation, time.sleep(n) would sleep much longer than n seconds?

Hi.

I'm writing some scripts with python, and I found sometimes, when I try to use time.sleep(1) to sleep 1 sec, it would actually sleep for 9 secs or even longer.

From python document, I saw this:

time.sleep(secs)
....
Also, the suspension time may be longer than requested by an arbitrary amount because of the scheduling of other activity in the system. 

So, my question: under what kind of condition, time.sleep would suspend longer time than expected?

Anybody got interested?

Best Regards.

[toc] | [next] | [standalone]

#73359

crow <wentlv@gmail.com>:

> I'm writing some scripts with python, and I found sometimes, when I
> try to use time.sleep(1) to sleep 1 sec, it would actually sleep for 9
> secs or even longer.
>
> [...]
>
> So, my question: under what kind of condition, time.sleep would
> suspend longer time than expected?

That could happen if your computer were extremely busy. Otherwise, I'd
say you are mistaken in your analysis, or you are running a broken
virtual machine.


Marko

[toc] | [prev] | [next] | [standalone]

#73360

On Wed, Jun 18, 2014 at 7:52 PM, crow <wentlv@gmail.com> wrote:
> So, my question: under what kind of condition, time.sleep would suspend longer time than expected?
>
> Anybody got interested?

There are several reasons the sleep time is always described as "at
least" that long. Firstly, your process will always sleep for some
multiple of the kernel's internal task switching resolution. That
doesn't explain why time.sleep(1) will sleep for nine seconds, but if
you try this, you'll see that at work:

>>> for i in range(1000): time.sleep(0.001)

In theory, that should be the same as time.sleep(1), right? Well, no.
On my systems it sleeps for 2-3 seconds at least, which suggests that
there's a minimum of 2-3 milliseconds of sleep time. And it could
easily sleep for a lot longer than that.

The second thing to note is that every PC you're ever likely to run
your code on [1] is a multitasking system. If some higher-priority
process [2] is running when your sleep expires, you won't preempt it,
so you'll sleep for longer. Or if your code or crucial data has been
paged out to disk, you have to wait to see it paged back in before you
can count that your sleep has finished. (This is especially noticeable
if you do something immediately after sleeping that you hadn't done
for a long time, so it'll tend to get paged out.)

Finally, it's entirely possible for some other process to explicitly
stop yours, at least on Unix systems. (I don't know if it's possible
on Windows.) If that happens, you won't wake up until you get
correspondingly continued. But chances are this isn't happening to
you, unless you're pressing Ctrl-Z to background a process or
something.

I've not often seen sleep(1) become nine seconds without a VERY good
reason, so there ought to be something that you can dig into. But just
remember that you can't use this for actual timing, and you're fine.
That is, don't do this:

t = time.time()
while True:
    t += 1
    time.sleep(1)

Because that's majorly flawed (for several reasons). If you let that
run for ten seconds, it'll probably be within 1-2 seconds; but if you
let that run all day, it could easily be out by a goodly number of
minutes.

ChrisA

[1] If you're running on a single-process real-time system, you *know*
the game rules are different, so you know to ignore what I'm saying
here. For 99%+ of python-list users, this will be true.
[2] Technically, if as many such processes are running as your
computer has CPU concurrency, eg one per core. Unless you have
execution affinities set. And other complexities. Look, I know this is
oversimplifying, okay! :)

[toc] | [prev] | [next] | [standalone]

#73366

Hi, Chris & Marko

Thanks for your reply.

I find the reason why my time.sleep take longer time.
In my script, I use wxPython to build up my GUI, and I open another thread to do network communications.
It turned out that if you create a wx.Frame & make it show up, then your time.sleep may sleep longer time than expected.

I will dig deeper for the root cause. Anyway, it's interesting.

Here is a sample code that can reproduce this issue, you need to wait for it to run for a while.
******************
import time
import threading
import wx

def sleep():
    while True:
        t = time.time()
        time.sleep(1)
        print "Actually sleep:", time.time() - t 


t1 = threading.Thread(target=sleep)
t1.start()

app =wx.App(False)
frame = wx.Frame(None, title="test")
frame.Show(True)
app.MainLoop()

[toc] | [prev] | [next] | [standalone]

#73388

On Thu, Jun 19, 2014 at 1:24 AM, crow <wentlv@gmail.com> wrote:
> Here is a sample code that can reproduce this issue, you need to wait for it to run for a while.
> ******************
> import time
> import threading
> import wx
>
> def sleep():
>     while True:
>         t = time.time()
>         time.sleep(1)
>         print "Actually sleep:", time.time() - t
>
>
> t1 = threading.Thread(target=sleep)
> t1.start()
>
> app =wx.App(False)
> frame = wx.Frame(None, title="test")
> frame.Show(True)
> app.MainLoop()

Okay... you're adding two important complications that you hadn't
mentioned originally: Python threads, and a GUI main loop. I could
explain the impact that each of these might have on time.sleep(), but
given your other recent questions, I'm going to say this instead:

Don't be afraid of the console.

When you write Python code, start by assuming that it will be run in
the standard "glass teletype" console. One thread, simple imperative
code, no GUI event loop, keep it simple. Later on, you can add fancy
features, but start by getting your main program code working in a
simpler environment.

In a lot of cases, a simple single-threaded console program is
actually all you need. You can transport that to other environments
easily (maybe run it under a web framework with minimal changes), and
it'll run perfectly on pretty much any build of Python, without any
fiddling around. And you spend so little time and code on your UI that
way; any half-decently-usable GUI will probably take you a good bit of
effort to code, but a good console UI just requires this:

something = raw_input("Enter something: ")
print("Result: "+result)

(Or, better: Upgrade to Python 3, and drop the "raw_" prefix. You get
other benefits too.)

Play with GUIs later, if at all. Start by getting the guts of your code right.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73389

Hi, Chris

Thanks for the suggestion. 
For my script, I want to download a picture from internet & show it in a window, that's why I use wxPython.

Well, I think I may can avoid sleep in wxPython in 2 ways:
1. Use web.py, let python do backend work, let browser show me everything. As you suggested.
2. Write 2 scripts, one script do network related works, sleep at will; the other one show GUI. Use pipe or socket for process communication.

Best Regards.

[toc] | [prev] | [next] | [standalone]

#73390

On Thu, Jun 19, 2014 at 11:41 AM, crow <wentlv@gmail.com> wrote:
> Thanks for the suggestion.
> For my script, I want to download a picture from internet & show it in a window, that's why I use wxPython.
>
> Well, I think I may can avoid sleep in wxPython in 2 ways:
> 1. Use web.py, let python do backend work, let browser show me everything. As you suggested.

I've done this one a few times, although on Linux I tend to just use
gnome-open or xdg-open and let the file be displayed with whatever's
configured - there's usually some sort of image viewer available on
the systems I use.

> 2. Write 2 scripts, one script do network related works, sleep at will; the other one show GUI. Use pipe or socket for process communication.

3. Write one script. First do the network stuff, sleep at will; then,
when it's finished downloading, show the window.

That might be easier!

ChrisA

[toc] | [prev] | [next] | [standalone]

#73397

Am 19.06.14 01:38, schrieb Chris Angelico:
> a good console UI just requires this:
>
> something = raw_input("Enter something: ")
> print("Result: "+result)

That is actually one of the worst console UIs possible. Almost all 
beginner's courses start with programs like that, requiring the user to 
key something in in the predefined order of the program. I've never seen 
a useful mature program working like that, only courseware and maybe 
crufty FORTRAN stuff from the past.

Unless there is good reason, make your program read the data from the 
command line args and from files given on the command line. This solves 
a lot of problems with user interaction, e.g. repeating and correcting 
commands. Programs written in the input() style are very annoying when 
you made a mistake in the 21st parameter of 30. Good interactive command 
line tools (e.g. gnuplot, Matlab, IPython, ...) exist, but they are 
complex; they bind to a readline library and implement a complex command 
language.

My advice:

1) First try parsing the command line. (Example: All Unix tools)

2) If you require more interaction and maybe state preservation, just 
write a couple of functions and run it in IPython (Example: SciPy)

3) Use a real GUI framework

It turns out, that 3) is actually not only easier to use, but often 
easier to write than 1)

	Christian

[toc] | [prev] | [next] | [standalone]

#73401

On Thu, Jun 19, 2014 at 5:18 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> Am 19.06.14 01:38, schrieb Chris Angelico:
>
>> a good console UI just requires this:
>>
>> something = raw_input("Enter something: ")
>> print("Result: "+result)
>
>
> That is actually one of the worst console UIs possible....
>
> My advice:
>
> 1) First try parsing the command line. (Example: All Unix tools)
>
> 2) If you require more interaction and maybe state preservation, just write
> a couple of functions and run it in IPython (Example: SciPy)
>
> 3) Use a real GUI framework
>
> It turns out, that 3) is actually not only easier to use, but often easier
> to write than 1)

I disagree. It may not be the *best* console UI, but it's not as bad
as you think. Yes, what I wrote was a massive oversimplification, but
compare this:

https://github.com/Rosuav/runningtime/blob/master/runningtime.py#L44

That's a simple, straight-forward UI. If you put the .py file onto
your desktop and double-click it, you'll see a series of prompts, and
this works on Windows, OS/2, probably Mac OS, and quite a few Linux
desktops. (Although I didn't put a shebang on that file, so it might
not work on your typical Linux.) How do you make something that
provides command line arguments to a double-clicked-on icon? Different
for every platform. (And seldom as easy as it is on OS/2.) If you run
that in a terminal, you'll see a series of prompts, and it works on
probably every Python implementation EVER. If you pull it up in IDLE,
it'll probably work there too, although I haven't tried it.

You're quite right that parsing the command line is often better for
long-term usability. But you try explaining to someone how to provide
args to a script. In fact, let's go a bit further: You can't assume
that Python was installed in any particular way, you've been told that
the OS is some version of Windows you're not familiar with (if you're
a Windows expert, then suppose this is some version of Mac OS that
you've never touched), and you're talking to the person over the
phone. This is, in fact, very similar to the situation I was in last
night, except that I wasn't even the person on the phone - my sister
was, and I was in the same room as she was. Now, you have no idea
whether typing "foo.py" will run it in Python, and if it does, in what
version; you have no idea whether "python.exe" is in PATH; and you
possibly can't even figure out how to open up a command prompt on that
system.

Yeah, I think [raw_]input() isn't so bad after all.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73407

Chris Angelico <rosuav@gmail.com>:

> Yeah, I think [raw_]input() isn't so bad after all.

I have never used it.

I *have* used getpass.getpass(). Unfortunately, it doesn't have a
corresponding prompt and raw input variant so I've had to essentially
copy over getpass() code and modify that:

   fd = os.open('/dev/tty', os.O_RDWR | os.O_NOCTTY)
   input = output = os.fdopen(fd, 'w+', 1)

etc.

Thing is, the standard streams are used for real work instead of
interacting with the user.


Marko

[toc] | [prev] | [next] | [standalone]

#73439

Am 19.06.14 09:42, schrieb Chris Angelico:
> On Thu, Jun 19, 2014 at 5:18 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:
>> Am 19.06.14 01:38, schrieb Chris Angelico:
>>
>>> a good console UI just requires this:
>>>
>>> something = raw_input("Enter something: ")
>>> print("Result: "+result)
>>
>>
>> That is actually one of the worst console UIs possible....

> I disagree. It may not be the *best* console UI, but it's not as bad
> as you think. Yes, what I wrote was a massive oversimplification, but
> compare this:
>
> https://github.com/Rosuav/runningtime/blob/master/runningtime.py#L44
>
> That's a simple, straight-forward UI. If you put the .py file onto
> your desktop and double-click it, you'll see a series of prompts, and
> this works on Windows, OS/2, probably Mac OS, and quite a few Linux
> desktops.

While I don't understand the purpose of the program (is it a game?), it 
shows exactly why this is a bad idea. Here is my try (OSX):

Apfelkiste:Tests chris$ python runningtime.py
Enter track length in m: 20
Enter speed limit [400km/h]: 300
Enter track length in m: 10
Enter speed limit [400km/h]: 100
Enter track length in m: 0
()
[  0.00] Power
[  7.85] Enter next section (10m speed 100)
[  8.00] Cruise
[  9.49] Enter next section (0m speed 0)
Traceback (most recent call last):
   File "runningtime.py", line 205, in <module>
     nextsection, nextspeed = next(section)
StopIteration

Suppose I want to run it again, but have length 30 in the first step.

1.)How am I going to do this? I have to restart it and key in 4 numbers, 
whereas I only wanted to change 1. Now let that be 10 segments.

2.) There is no way to save the input or the result. Or it may not be 
obvious. I could prepare a file with the numbers, then do

	python runningtime.py <input > output
But then I don't see the prompts and have to be careful not to enter a 
speed for a length.

3.) The program doesn't tell me how to break out of the entering process 
and start the computation. Is it a 0? Is it an empty string? I'm getting 
Tracebacks in either case (could be wrong python version, I'm using the 
OSX default 2.7.2)

All these problems arise because the program forces me to enter the data 
in a predefined sequence. So no, this is not a good user experience. In 
a GUI it would be trivial to have an editable listbox for track length 
and speed, and a set of buttons to save, load, run the computation.

	Christian

[toc] | [prev] | [next] | [standalone]

#73442

On Fri, Jun 20, 2014 at 3:17 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> While I don't understand the purpose of the program (is it a game?), it
> shows exactly why this is a bad idea.

It's a tool for calculating stuff about railway tracks. Never mind
about the details of what it does with the info, but the input phase
you're talking about is basically building up a speed map of the track
- straight-line track has an effective speed limit of 400km/h, curves
have lower limits.

> Here is my try (OSX):
>
> Apfelkiste:Tests chris$ python runningtime.py
> Enter track length in m: 20
> Enter speed limit [400km/h]: 300
> Enter track length in m: 10
> Enter speed limit [400km/h]: 100
> Enter track length in m: 0
> ()
> [  0.00] Power
> [  7.85] Enter next section (10m speed 100)
> [  8.00] Cruise
> [  9.49] Enter next section (0m speed 0)
> Traceback (most recent call last):
>   File "runningtime.py", line 205, in <module>
>     nextsection, nextspeed = next(section)
> StopIteration

Well, you didn't put in enough track for the train to even get
started. Basically, you built thirty meters of railway line, then put
a suburban train on it (264 meters long - the figure's at the top of
the program, although I wouldn't expect anyone to know it; however, it
should make perfect sense that a train is more than 30m long!). So the
program crashed, because this is an early alpha that's designed to be
used by someone who knows what he's doing. If you crank those figures
up a bit and, say, put a few km of track down, then it won't bomb.

> Suppose I want to run it again, but have length 30 in the first step.

That would still be extremely odd, but suppose you want length 3000 in
the first step.

> 1.)How am I going to do this? I have to restart it and key in 4 numbers,
> whereas I only wanted to change 1. Now let that be 10 segments.
>
> 2.) There is no way to save the input or the result. Or it may not be
> obvious. I could prepare a file with the numbers, then do
>
>         python runningtime.py <input > output
> But then I don't see the prompts and have to be careful not to enter a speed
> for a length.

The program is designed to be used with either copy/paste or
redirection (you'll note a line comment in the code about redirection)
for that sort of scenario, and there's a TODO in the code to have it
read sys.argv. Thing is, you're looking at an extremely early alpha
that I developed alongside the one person who actually intends to use
it; any time spent on a GUI would be wasted at this stage, and even
parsing sys.argv to figure out which are file names and which are
other things would probably be a waste. Making something more
resilient would require design effort (first thought: read two numbers
per line, the length and the curve speed, and if it's a single number,
it's straight track at maximum speed) and thus would require
explanation ("so you need to put the two numbers on the same line").
It can be left for later.

Main point being that the existing UI works, and took almost no
effort. It gives us 99% of what we need for 1% of the work. The rest
of what we want can be obtained with small refinements, rather than a
full rewrite into a GUI.

> 3.) The program doesn't tell me how to break out of the entering process and
> start the computation. Is it a 0? Is it an empty string? I'm getting
> Tracebacks in either case (could be wrong python version, I'm using the OSX
> default 2.7.2)

The traceback when you enter a 0 is because you didn't give it enough
track to work with. The traceback on the empty string is because
that's a Python 3 program - it uses input() not raw_input() - and
you're asking it to eval an empty string. To be honest, I'm impressed
that it works as well as it does on 2.7; I never tested it. Definitely
some of the multi-arg print calls will produce messy output on 2.7
(they'll be printing tuples), but apparently the rest of the code is
so simple that a single __future__ directive and "try: input=raw_input
 except NameError: pass" would make it work on 2.7. But we don't need
2.7 support.

> All these problems arise because the program forces me to enter the data in
> a predefined sequence. So no, this is not a good user experience. In a GUI
> it would be trivial to have an editable listbox for track length and speed,
> and a set of buttons to save, load, run the computation.

You're thinking in terms of the wrong sort of user and the wrong
scenario. Is it "a good user experience" to drop you into a completely
promptless input space, wait for you to hit Ctrl-D, and then echo back
every line you typed, in order? Because that's what the standard Unix
sort command does if you give it no args and no redirection. Is that
horrible design? Nope.

What runningtime.py has may not be 100% perfect, but it's better than
the editable listbox for several reasons:

1) Editing is actually not a common operation. Normal is to go through
a piece of track (as defined by some external resource), figure out
how long it'll take to go through it, and finish. Maybe compare two
tracks, which might start with the same few sections and then diverge
(do we go left or right around this obstacle?); in that case, copy and
paste of the early elements would be all you need for this UI, but
with an editable listbox, you'd have to go in and delete the half that
are wrong in order to retain the half that are right. Worse if it's
more than half different.

2) Time spent on the UI is time not spent on the guts of the program.
ESPECIALLY when I have severely limited time working with the client,
I don't want to waste it faffing around with incidentals. I want to
spend that time getting the crucial mathematics right. (Yeah. Like
River Tam and Queen Elsa, we did the math.)

3) This method makes it trivially easy to save to a file (eg
redirection). If you do it with a GUI, you then need a separate (and
separately-coded) facility to save and load. Glass teletype gives you
all that for free.

If Python had an sscanf-like function [1], I'd probably have made the
UI something like length,speed=sscanf("%d %d"), and that would be a
bit of an improvement (I think). The sequential nature of it isn't a
problem, though, so this would be a very minor thing. (And of course,
I could just read a string and manually parse. But that flies against
the principle of "waste no time on the UI when you're already short of
time for the maths".) What we have there is pretty good as it is, at
no effort.

ChrisA

[1] Something safer than C's one, of course. Pike does this:
http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/sscanf.html

[toc] | [prev] | [next] | [standalone]

#73443

On 6/19/2014 3:42 AM, Chris Angelico wrote:
> On Thu, Jun 19, 2014 at 5:18 PM, Christian Gollwitzer <auriocus@gmx.de> wrote:

>> My advice:
>>
>> 1) First try parsing the command line. (Example: All Unix tools)
>>
>> 2) If you require more interaction and maybe state preservation, just write
>> a couple of functions and run it in IPython (Example: SciPy)
>>
>> 3) Use a real GUI framework
>>
>> It turns out, that 3) is actually not only easier to use, but often easier
>> to write than 1)
>
> I disagree. It may not be the *best* console UI, but it's not as bad
> as you think. Yes, what I wrote was a massive oversimplification, but
> compare this:
>
> https://github.com/Rosuav/runningtime/blob/master/runningtime.py#L44
>
> That's a simple, straight-forward UI. If you put the .py file onto
> your desktop and double-click it, you'll see a series of prompts, and
> this works on Windows, OS/2, probably Mac OS, and quite a few Linux
> desktops. (Although I didn't put a shebang on that file, so it might
> not work on your typical Linux.) How do you make something that
> provides command line arguments to a double-clicked-on icon? Different
> for every platform. (And seldom as easy as it is on OS/2.) If you run
> that in a terminal, you'll see a series of prompts, and it works on
> probably every Python implementation EVER. If you pull it up in IDLE,
> it'll probably work there too, although I haven't tried it.

Most any* console script runs fine** in Idle once you load it into the 
editor and press F5. Prompts and prints go the shell window (default 
blue on white) and input comes from the same (default black on white).

* I said most because there must be exceptions, but have no 
characterization.

** Better than the windows console in some respects.

I hope that by the end of the summer, the requirement to load in the 
editor will be gone. (Run F5 saves to a file anyway for actual 
execution.) There should also be an option to put output in a new window.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#73444

On Fri, Jun 20, 2014 at 12:33 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> Most any* console script runs fine** in Idle once you load it into the
> editor and press F5. Prompts and prints go the shell window (default blue on
> white) and input comes from the same (default black on white).

I figured it'd be easy, just couldn't say for sure. (To me, IDLE is
primarily an interactive interpreter, rather than an editor / script
runner.) Thanks for confirming.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web