Ian Kelly :
> On Thu, Dec 4, 2014 at 3:44 PM, Marko Rauhamaa wrote:
>> So, what's the semantics of time.sleep(), select.select() et al wrt
>> process or machine suspension?
>
> Rather than continue to speculate, I just tested this.
The test, of course, can only have one useful result...
> So it
On Thu, Dec 4, 2014 at 3:44 PM, Marko Rauhamaa wrote:
>
> Ian Kelly :
>
> > It's not clear to me whether those cases are relevant to the rollover
> > concern anyway. I wouldn't be shocked if the GetTickCount() function
> > simply stopped increasing while the system is suspended, since after
> > al
Lele Gaifax wrote:
> Steven D'Aprano writes:
>
>> The most conservative approach is to assume that while you're suspended,
>> *everything else* is suspended too, so when you resume you still have to
>> sleep for the full N seconds.
>
> That's an intriguing interpretation of what sleep() should
Dave Angel writes:
...many words about sleep()...
> Since the OS has no way of knowing whether the thing being waited for
> is a thread, another process, a human being, a network operation, or
> the end of the world, the interpretation of sleep needs to be the most
> conservative one. There are
Steven D'Aprano writes:
> The most conservative approach is to assume that while you're suspended,
> *everything else* is suspended too, so when you resume you still have to
> sleep for the full N seconds.
That's an intriguing interpretation of what sleep() should do, but I
fail to see *how* the
Steven D'Aprano :
> Unfortunately a lot of systems get that wrong. E.g. I just ran "sleep
> 30" from my Linux shell, immediately paused it using Ctrl-Z, waited a
> couple of minutes, and used fg to continue. It returned immediately.
>
> Why is this behaviour wrong?
I think the #1 thing is to spec
On 12/04/2014 09:54 PM, Steven D'Aprano wrote:
Dave Angel wrote:
On 12/04/2014 07:39 PM, Steven D'Aprano wrote:
Marko Rauhamaa wrote:
So, if I call
time.sleep(86400)
and the program is suspended for 24 hours, should time.sleep() return
right after it is resumed or after another 24 hours?
Dave Angel wrote:
> On 12/04/2014 07:39 PM, Steven D'Aprano wrote:
>> Marko Rauhamaa wrote:
>>
>>> So, if I call
>>>
>>> time.sleep(86400)
>>>
>>> and the program is suspended for 24 hours, should time.sleep() return
>>> right after it is resumed or after another 24 hours?
>>
>> If the program is
On 12/04/2014 07:39 PM, Steven D'Aprano wrote:
Marko Rauhamaa wrote:
So, if I call
time.sleep(86400)
and the program is suspended for 24 hours, should time.sleep() return
right after it is resumed or after another 24 hours?
If the program is suspended, then no time should pass for that prog
On Thu, 04 Dec 2014 16:25:44 +0100, ast wrote:
> There is no roll over problem with time.time() since the very
> first one in planned far in the future, but time.time() can go
> backward when a date update throught NTP server is done.
> time.monotonic() is monotonic but roll over often (every 49.
Marko Rauhamaa wrote:
> So, if I call
>
> time.sleep(86400)
>
> and the program is suspended for 24 hours, should time.sleep() return
> right after it is resumed or after another 24 hours?
If the program is suspended, then no time should pass for that program.
Since sleep() is given in terms of
Ian Kelly :
> It's not clear to me whether those cases are relevant to the rollover
> concern anyway. I wouldn't be shocked if the GetTickCount() function
> simply stopped increasing while the system is suspended, since after
> all it's not "ticking" during that time.
So, what's the semantics of
On Thu, Dec 4, 2014 at 1:24 PM, Akira Li <4kir4...@gmail.com> wrote:
>
> Ian Kelly writes:
> > This seems like a lot of effort to unreliably design around a problem
that
> > will matter to only a tiny fraction of users.
>
> - people's computers are mostly on batteries (laptops, tablets,
> smartp
Chris Angelico :
> Even when I do suspend a VM, I often terminate applications in it, and
> just use suspension to save having to boot the OS every time.
One interesting detail is DHCP leases.
When it is resumed from suspension, a linux computer thinks it still has
the old IP address, which migh
On Fri, Dec 5, 2014 at 7:24 AM, Akira Li <4kir4...@gmail.com> wrote:
>> This seems like a lot of effort to unreliably design around a problem that
>> will matter to only a tiny fraction of users.
>
> - people's computers are mostly on batteries (laptops, tablets,
> smartphones) -- "suspended from
Ian Kelly writes:
> On Thu, Dec 4, 2014 at 11:09 AM, Marko Rauhamaa wrote:
>>
>> Chris Angelico :
>>
>> > It's not a Python issue. Python can't do anything more than ask the
>> > system, and if the system's value rolls over several times a year,
>> > Python can't magically cure that. The informa
On Fri, Dec 5, 2014 at 5:44 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> ... what you said There's no way to guarantee to keep calling the
>> function. You have to depend on upstream.
>
> The caveats I listed are real concerns for the modern-day programmer.
> However, they are of a different
On Thu, Dec 4, 2014 at 11:09 AM, Marko Rauhamaa wrote:
>
> Chris Angelico :
>
> > It's not a Python issue. Python can't do anything more than ask the
> > system, and if the system's value rolls over several times a year,
> > Python can't magically cure that. The information has already been
> > lo
Chris Angelico :
> ... what you said There's no way to guarantee to keep calling the
> function. You have to depend on upstream.
The caveats I listed are real concerns for the modern-day programmer.
However, they are of a different nature than the complaint against
time.monotonic().
Marko
--
On Fri, Dec 5, 2014 at 5:09 AM, Marko Rauhamaa wrote:
> Sure it could by having an invisible background thread occasionally call
> time.monotonic(). It could even be done on the side without a thread.
No, it can't be solved by anything in that process, because...
> * the program could be stoppe
Chris Angelico :
> It's not a Python issue. Python can't do anything more than ask the
> system, and if the system's value rolls over several times a year,
> Python can't magically cure that. The information has already been
> lost.
Sure it could by having an invisible background thread occasiona
On Thu, Dec 4, 2014, at 10:50, Marko Rauhamaa wrote:
> That is, the internal integer wrap is not guarded against between the
> calls to time.monotonic(), maybe.
Looking at the code, it looks like it does guard against the rollover,
though if you let your program run for 49.7 days _without_ calling
On Fri, Dec 5, 2014 at 3:21 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> The implication is that if you go more than 49 days without calling
>> the function on old Windows systems, rollovers could be missed, which
>> is good to know about.
>
> The implication is all but clear, but that was my susp
Ian Kelly :
> The implication is that if you go more than 49 days without calling
> the function on old Windows systems, rollovers could be missed, which
> is good to know about.
The implication is all but clear, but that was my suspicion. It would be
so bad that the documentation should be much
On Fri, Dec 5, 2014 at 3:05 AM, Ian Kelly wrote:
> On Dec 4, 2014 8:56 AM, "Marko Rauhamaa" wrote:
>>
>> "ast" :
>>
>> > Does any body know when time.monotonic() rolls over ?
>>
>> Never, according to the documentation you linked.
>>
>> Admittedly, the documentation confuses the reader by chattin
On Dec 4, 2014 8:56 AM, "Marko Rauhamaa" wrote:
>
> "ast" :
>
> > Does any body know when time.monotonic() rolls over ?
>
> Never, according to the documentation you linked.
>
> Admittedly, the documentation confuses the reader by chatting about some
> irrelevant internal Windows details.
Not ent
"ast" :
> Does any body know when time.monotonic() rolls over ?
Never, according to the documentation you linked.
Admittedly, the documentation confuses the reader by chatting about some
irrelevant internal Windows details.
Also, the tone of the documentation raises a suspicion that this code
m
27 matches
Mail list logo
