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 _GLIBCXX_HAS_SYS_SYSCALL_H
#include <sys/syscall.h>
#endif
#if defined (SYS_clock_gettime) && defined (CLOCK_MONOTONIC)
syscall (SYS_clock_gettime, CLOCK_MONOTONIC, &tp);
#endif
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.
Jakub
