This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 05/23] sysdeps/timespec_get: Use clock_gettime64 if avaliable
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: Florian Weimer <fweimer at redhat dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Palmer Dabbelt <palmer at sifive dot com>, <macro at wdc dot com>, Zong Li <zongbox at gmail dot com>, Alistair Francis <alistair23 at gmail dot com>
- Date: Thu, 25 Jul 2019 20:14:11 +0000
- Subject: Re: [RFC v3 05/23] sysdeps/timespec_get: Use clock_gettime64 if avaliable
- References: <cover.1563321715.git.alistair.francis@wdc.com> <0d116a8faab58db1952a256c6cb75e7b0f9af444.1563321715.git.alistair.francis@wdc.com> <87zhlddz8v.fsf@oldenburg2.str.redhat.com> <CAK8P3a0qTNpdXdHPhoMaJEYete29CB=OGRjOQixvTSj2veM3Qw@mail.gmail.com>
On Wed, 17 Jul 2019, Arnd Bergmann wrote:
> > I don't think this is right. I think you need to cache clock_gettime64
> > support somewhere and avoid trying to call the non-existing system call
> > again and again.
>
> How important is this? It sounds like a micro-optimization for a case that
> very few people are going to hit, given that running an application with
> 64-bit time_t on an old kernel will likely hit other bugs that glibc cannot
> deal with.
It's a generic design question for all the time64 patches that might end
up using one or another syscall at runtime depending on kernel support -
we'll need to arrive at a consensus on whether such caching (probably
shared between all relevant syscalls) is desired. It's not clear to me
whether the case of _TIME_BITS=64 on an old kernel will end up as a rare
case or not. And as per my previous comments, many existing functions
using 32-bit times should end up as thin wrappers round functions using
64-bit times, so potentially making two syscalls every time unless there
is such caching.
--
Joseph S. Myers
joseph@codesourcery.com