This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] Default to --enable-libstdcxx-time=auto
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Date: Wed, 22 May 2013 14:35:40 +0200
- Subject: Re: [patch] Default to --enable-libstdcxx-time=auto
- References: <CAH6eHdTgTspzbfHhD3uDwDVD3uXAapb_NMZ0jAZ-4-UjfD4H4g at mail dot gmail dot com> <519C942D dot 6050100 at oracle dot com> <CAH6eHdTjdi75WSwKYfdGBtOeQwbsSvMbzzxo24qofMexFSmETA at mail dot gmail dot com> <519C9AF5 dot 8090300 at oracle dot com> <519C9CBC dot 4050606 at oracle dot com> <519C9E3B dot 60609 at oracle dot com> <CAH6eHdRXAK1r0g7u+50RobAxTo=6DJsvRZzo75m7x+5ir3opKQ at mail dot gmail dot com> <CAH6eHdS5gqa2nfNJfC0zy9FJq4amgjJbtUuEASM_Qw0GZ8-9aA at mail dot gmail dot com> <20130522111543 dot GG1377 at tucnak dot redhat dot com> <CAH6eHdR0MocSNhvD_xRfhcYiaGugs8P++oJnTyy5DSAiDh=hPg at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, May 22, 2013 at 12:49:44PM +0100, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
> > If now() can be perhaps with worse precision emulated in configurations not
> > built against glibc 2.17, perhaps best solution would be to
> > add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
> > 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
> > alias to that.
> The problem for steady_clock::now() isn't one of precision, it's that
> it isn't steady if we don't use the monotonic clock. We could define
> a non-steady steady_clock (with the same precision as system_clock)
> but is that helpful to users? If that's what we want then yes, we can
> do the symbol versioning you suggest.
There are two things. One is offering to use steady_clock::now() at
compile time, even if we know the clock isn't steady (here sure, I think
preferrably don't offer that), but the second thing is, if you have
already linked program which uses steady clock, what is better, not be
able to dynamically link it at all (steady_clock use might be in some
library and you don't ever call now() in your program), or to
abort/std::terminate when now() is called in your program, or you offer
non-steady clock instead. Or, have you also considered just using
for this routine
#if defined (SYS_clock_gettime) && defined (CLOCK_MONOTONIC)
syscall (SYS_clock_gettime, CLOCK_MONOTONIC, &tp);
if clock_gettime isn't available, at least on Linux?
The implementation seems to ignore ENOSYS from clock_gettime, so ignoring it
even here wouldn't make it worse.