>> We're going around in circles. I'm not asking what sleep does, I want
>> on principle a timer that does the same thing as sleep(), regardless
>> of how sleep() works. So if on some OS sleep() uses the same algorithm
>> as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on
>> some ot
>> sleep() is implemented in the kernel. The kernel is notified when a
>> clock is set, and so can choose how to handle time adjustement. Most
>> "sleeping" functions use the system clock but don't care of clock
>> adjustement.
>
> We're going around in circles. I'm not asking what sleep does, I wa
On 09Apr2012 13:26, Victor Stinner wrote:
| > | On Windows, GetProcessTimes() has not a "high-resolution": it has a
| > | accuracy of 1 ms in the best case.
| >
| > This page:
| >
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683223%28v=vs.85%29.aspx
| > says "100-nanosecond time uni
> | * time.process_time(): High-resolution (?) per-process timer from the
> | CPU. (other possible names: time.process_cpu_time() or
> | time.cpu_time())
>
> POSIX offers CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID that
> seem to suit this need, depending on your threading situation (and
2012/4/9 Guido van Rossum :
>>You may need two clocks
>> for this:
>> * time.perf_counter(): high-resolution timer for benchmarking, count
>> time elasped during a sleep
>> * time.process_time(): High-resolution (?) per-process timer from the
>> CPU. (other possible names: time.process_cpu_time()
On Sun, Apr 8, 2012 at 5:00 PM, Victor Stinner wrote:
>> IOW "What's good enough for sleep() is good enough for
>> user-implemented timeouts and scheduling." as a way to reach at least
>> one decision for a platform with agreed-upon cross-platform
>> characteristics that are useful.
>
> sleep() is
On 09Apr2012 02:00, Victor Stinner wrote:
| > I personally have a need for one potentially different clock -- to
| > measure short intervals for benchmarks and profiling. This might be
| > called time.performancetimer()?
|
| I deferred this topic because it is unclear to me if such timer has to
|
> IOW "What's good enough for sleep() is good enough for
> user-implemented timeouts and scheduling." as a way to reach at least
> one decision for a platform with agreed-upon cross-platform
> characteristics that are useful.
sleep() is implemented in the kernel. The kernel is notified when a
cloc
On Sun, 8 Apr 2012 07:29:30 -0700
Guido van Rossum wrote:
>
> What to name it can't be decided this way, although I might put
> forward time.sleeptimer().
interval_timer() ?
I would suggest timer() simply, but it's too close to time().
> I personally have a need for one potentially different cl
On Sun, Apr 8, 2012 at 3:42 AM, Antoine Pitrou wrote:
>
>> | I made the same suggestion earlier but I don't know that anyone did
>> | anything with it. :-( It would be nice to know what clock sleep() uses
>> | on each of the major platforms.
>>
>> I saw it but didn't know what I could do with it,
> | I made the same suggestion earlier but I don't know that anyone did
> | anything with it. :-( It would be nice to know what clock sleep() uses
> | on each of the major platforms.
>
> I saw it but didn't know what I could do with it, or even if it can be
> found out in any very general sense.
On 07Apr2012 18:49, Guido van Rossum wrote:
| On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
| wrote:
| > Just to clarify my previous post.
| > It seems clear that benchmarking and timeout logic would benefit
| > from a clock that cannot be adjusted by NTP.
Indeed.
Except for calendar program
On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
wrote:
> Just to clarify my previous post.
>
> It seems clear that benchmarking and timeout logic would benefit from a clock
> that cannot be adjusted by NTP.
>
> I'm unclear on whether time.sleep() will be based on the same clock so that
> timeo
Victor et al,
Just an update note:
I've started marking up clocks with attributes; not yet complete and I
still need to make a small C extension to present the system clocks to
Python space (which means learning to do that, too).
But you can glance over the start on it here:
https://bitbucket
Just to clarify my previous post.
It seems clear that benchmarking and timeout logic would benefit from a clock
that cannot be adjusted by NTP.
I'm unclear on whether time.sleep() will be based on the same clock so that
timeouts and sleeps are on the same basis.
For scheduling logic (such as t
it a "monotonic clock"
(was: PEP 418 is too divisive and confusing and should be postponed)
I'd like to veto wall clock because to me that's the clock on my wall, i.e.
local time. Otherwise I like the way this thread is going.
--Guido van Rossum (sent from Android phone)
On A
On Apr 7, 2012, at 3:08 AM, Paul Moore wrote:
> Use cases:
>
> Display the current time to a human (e.g. display a calendar or draw a
> wall clock): use system clock, i.e. time.time() or
> datetime.datetime.now().
> Event scheduler, timeout: time.monotonic().
> Benchmark, profiling: time.clock()
On 07Apr2012 01:47, Victor Stinner wrote:
| I don't understand this definition. All clocks have a clock drift.
| This is just one exception: atomic clocks, but such clocks are rare
| and very expensive.
They've got drift too. It is generally very small.
Anecdote: I used to keep my wristwatch (oh
On 7 April 2012 09:12, Stephen J. Turnbull wrote:
>
> I don't think that's a reason that should be considered. There just
> doesn't seem to be a single best clock, nor do clocks of similar
> character seem to be easy to find across platforms. So the reasons
> I'd like to see are of the form "we
On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner wrote:
> "Objects of class steady_clock represent clocks for which values of
> time_point advance at a steady rate relative to real time. That is,
> the clock may not be adjusted."
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#
On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner
wrote:
> On Linux, I now prefer
> to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW
> (monotonic and steady as defined by C++) *because* its frequency is
> adjusted.
I don't think that's a reason that should be considered. There just
doe
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
For the "C++" p
> | This is the original reason for the original defect (issue 10278)
> | unix' clock() doesn't actually provide a clock in this sense, it provides a
> resource usage metric.
>
> Yeah:-( Its help says "Return the CPU time or real time since [...]".
> Two very different things, as demonstrated. I s
On 06Apr2012 17:07, Kristj�n Valur J�nsson wrote:
| Steven D'Aprano:
| > I think that this is incorrect.
| > py> time.clock(); time.sleep(10); time.clock()
| > 0.41
| > 0.41
|
| This is the original reason for the original defect (issue 10278)
| unix' clock() doesn't actually provide a clock in th
On 06Apr2012 15:19, I wrote:
| On 06Apr2012 14:31, Steven D'Aprano wrote:
| | Here is a non-monotonic sequence:
| |
| | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8
| |
| | This isn't steady either, because it jumps backwards.
| |
| | To be steady, it MUST also be monotonic. If you think that it is
s+kristjan=ccpgames@python.org] fyrir hönd Steven
D'Aprano [st...@pearwood.info]
Sent: 6. apríl 2012 10:12
To: Python-Dev
Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock"
(was: PEP 418 is too divisive and confusing and should be postponed)
ictor.stin...@gmail.com]
Sent: 6. apríl 2012 14:32
To: Zooko Wilcox-O'Hearn
Cc: Python-Dev
Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock"
(was: PEP 418 is too divisive and confusing and should be postponed)
The C++ Timeout Specification uses the following
I'd like to veto wall clock because to me that's the clock on my wall, i.e.
local time. Otherwise I like the way this thread is going.
--Guido van Rossum (sent from Android phone)
On Apr 6, 2012 4:57 AM, "Paul Moore" wrote:
> On 6 April 2012 11:12, Steven D'Aprano wrote:
>
>> Glyph Lefkowitz wr
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
Python cannot g
On 6 April 2012 11:12, Steven D'Aprano wrote:
> Glyph Lefkowitz wrote:
>
>> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
>>
>
> 2. Those who think that "monotonic clock" means a clock that never jumps,
>>> and that runs at a rate approximating the rate of real time. This is a
>>> very
Glyph Lefkowitz wrote:
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
2. Those who think that "monotonic clock" means a clock that never jumps,
and that runs at a rate approximating the rate of real time. This is a
very useful kind of clock to have! It is what C++ now calls a "steady
On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz wrote:
> There seems to be a persistent desire in this discussion to specify and
> define these flaws out of existence, where this API really should instead be
> embracing the flaws and classifying them.
That seems to be precisely what Cameron is a
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
> On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing
> wrote:
>>
>> This is the strict mathematical meaning of the word "monotonic", but the way
>> it's used in relation to OS clocks, it seems to mean rather more than that.
>
> Yep. As far as I
On 06Apr2012 14:31, Steven D'Aprano wrote:
| Cameron Simpson wrote:
| > | The main reason to use the word "monotonic clock" to refer to the
| > | second concept is that POSIX does so, but since Mac OS X, Solaris,
| > | Windows, and C++ have all avoided following POSIX's mistake, I think
| > | Pyth
Cameron Simpson wrote:
| The main reason to use the word "monotonic clock" to refer to the
| second concept is that POSIX does so, but since Mac OS X, Solaris,
| Windows, and C++ have all avoided following POSIX's mistake, I think
| Python should too.
No. If it is not monotonic, DO NOT CALL IT
On 05Apr2012 21:07, Zooko Wilcox-O'Hearn wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing
wrote:
| > This is the strict mathematical meaning of the word "monotonic",
| > but the way it's used in relation to OS clocks, it seems to mean rather
| > more than that.
|
| Yep. As far as I can tell,
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing wrote:
>
> This is the strict mathematical meaning of the word "monotonic", but the way
> it's used in relation to OS clocks, it seems to mean rather more than that.
Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.
There se
37 matches
Mail list logo
