On 23 May 2013 11:28, Jakub Jelinek wrote: > On Wed, May 22, 2013 at 02:35:40PM +0200, Jakub Jelinek wrote: >> 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. > > I mean something like completely untested following patch, then it would > be pretty much enabled for all non-prehistoric Linux builds (there is a risk > of it returning garbage on 2.4.x and earlier kernels, if you compile it on > something that defines __NR_clock_gettime in their headers, but the exact > same risk is if you do the same with --enable-libstdcxx-time=rt > (clock_gettime wrapper in glibc will return -1/ENOSYS in that case, so will > the syscall, but chrono.cc seems to ignore that return value)). > 2.6+ kernels (2004-ish and later or so) should support CLOCK_MONOTONIC just
This looks great to me, thanks. > fine. Of course, there is a possibility of fallback, at least for the > clock_gettime/syscall CLOCK_RUNTIME or gettimeofday, if they fail, fall > through into the time case, and for CLOCK_MONOTONIC perhaps just lie and > return time as well, shouldn't really affect almost anybody. We should consider doing that yes, but it's less urgent. > Still, the ABI question is there, would we want to apply to 4.8.1 (can we > get agreement on that RSN, this is pretty much the only blocker for 4.8.1 > rc2 right now) and, would we export that symbol as @@GLIBCXX_3.4.18 (with > all trunk @@GLIBCXX_3.4.18 symbols moved to 3.4.19) and add @GLIBCXX_3.4.17 > alias for backwards compatibility with those that configured with > --enable-libstdcxx-time=rt ? I like that plan.
