This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [ping2][PATCH v2][BZ #12515] Improve precision of clock function
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org, Roland McGrath <roland at hack dot frob dot com>
- Date: Tue, 11 Jun 2013 19:24:23 +0530
- Subject: Re: [ping2][PATCH v2][BZ #12515] Improve precision of clock function
- References: <20130521145611 dot GM8927 at spoyarek dot pnq dot redhat dot com> <20130521151839 dot GA18430 at domone dot kolej dot mff dot cuni dot cz> <20130521153442 dot GO8927 at spoyarek dot pnq dot redhat dot com> <519B9A09 dot 6030305 at cs dot ucla dot edu> <20130521161441 dot GQ8927 at spoyarek dot pnq dot redhat dot com> <20130603092604 dot GL2145 at spoyarek dot pnq dot redhat dot com> <20130610083821 dot GD1570 at spoyarek dot pnq dot redhat dot com> <51B66522 dot 1060008 at cs dot ucla dot edu>
On Mon, Jun 10, 2013 at 04:45:38PM -0700, Paul Eggert wrote:
> On 06/10/13 01:38, Siddhesh Poyarekar wrote:
>
> >>> + if (__clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &ts) == 0)
> >>> + return (ts.tv_sec * CLOCKS_PER_SEC
> >>> + + ts.tv_nsec / (1000000000 / CLOCKS_PER_SEC));
>
> Sorry, now that I'm thinking about it, I thought of two more
> things.
>
> First, the above code relies on wraparound arithmetic after
> signed integer overflow, assuming time_t is signed, but GCC
> doesn't guarantee this by default. So, should
Shouldn't this matter only when we're actually doing an overflow
check? We're not doing that in this patch, so we could hold it off
till the next iteration where we try to detect overflow and return an
error. Right now, all this will do is return a spurious result, so it
is bug-for-bug compatible with the older version.
> the function containing the above code be preceded by a pragma,
> like this?
>
> #pragma GCC optimize ("wrapv")
>
> I ask this because I don't know what glibc's assumptions are
> about integer overflow -- when there's a signed integer overflow
> does glibc assume -fwrapv behavior or undefined behavior?
I don't know either.
> Are we deferring the second issue for now?
> If so, we should probably put in a comment about it,
> since it'll come up again eventually....
I think we could defer all discussion about overflow handling till we
actually get to fixing it. There are bug reports that document this
already, so I don't see the point of adding a comment. I could if you
feel strongly about it, since I don't.
I've re-attached the patch (without changes or now) for review since
Roland asked for it.
Siddhesh
2013-05-21 Siddhesh Poyarekar <siddhesh@redhat.com>
Paul Eggert <eggert@cs.ucla.edu>
[BZ #12515]
* sysdeps/unix/sysv/linux/clock.c (clock): Use result from
CLOCK_PROCESS_CPUTIME_ID clock if available.
diff --git a/sysdeps/unix/sysv/linux/clock.c b/sysdeps/unix/sysv/linux/clock.c
index 5268d33..e4e2065 100644
--- a/sysdeps/unix/sysv/linux/clock.c
+++ b/sysdeps/unix/sysv/linux/clock.c
@@ -23,6 +23,14 @@
clock_t
clock (void)
{
+ struct timespec ts;
+
+ if (__clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &ts) == 0)
+ return (ts.tv_sec * CLOCKS_PER_SEC
+ + ts.tv_nsec / (1000000000 / CLOCKS_PER_SEC));
+
+ /* clock_gettime failed. This will only occur if CLOCK_PROCESS_CPUTIME_ID is
+ not supported by the kernel. Fall back to __times. */
struct tms buf;
long clk_tck = __sysconf (_SC_CLK_TCK);