[erlang-questions] is Linux's clock_gettime still "not stable" enough for Erlang?

[mats cronqvist]

Roger Critchlow <rec@REDACTED> writes:

> Maybe I'm confused, but I think the problem is that configure ignores
> the test result under linux.

  no, I think you're right. It does seem like they've disabled
  CLOCK_PROCESS_CPUTIME_ID on linux.

> My config.log for otp_src_R13B says:
>
> configure:19638: checking if clock_gettime can be used to get process CPU time
> configure:19682: gcc -o conftest -g -O2 -I/usr/local/src/otp_src_R13B/erts/
> x86_64-unknown-linux-gnu    -D_GNU_SOURCE   conftest.c -lrt >&5
> configure:19686: $? = 0
> configure:19692: ./conftest
> configure:19696: $? = 0
> configure:19715: result: not stable, disabled
>
> The compile of the test (line 19682) succeeded (line 19686), the test (line
> 19692) succeeded (line 19696), but the result of the test is ignored because
> the ac_local.m4 code mentioned at the start of the thread.  That code ignores
> the result of the test, which is recorded in $erl_clock_gettime, when running
> linux.
>
>     case $host_os in
>         linux*)
>             AC_MSG_RESULT([not stable, disabled])
>             LIBRT=$xrtlib
>             ;;
>         *)
>             case $erl_clock_gettime in
>                   true)
>                     AC_DEFINE(HAVE_CLOCK_GETTIME,[],
>                           [define if clock_gettime() works for getting process
> time])
>                     AC_MSG_RESULT(using clock_gettime)
>                     LIBRT=-lrt
>                     ;;
>                   *)
>                     AC_MSG_RESULT(not working)
>                     LIBRT=$xrtlib
>                     ;;
>             esac
>             ;;
>     esac
>
> -- rec --
>
> On Thu, May 14, 2009 at 2:47 AM, mats cronqvist <masse@REDACTED> wrote:
>
>     Joe Williams <joe@REDACTED> writes:
>    
>     > According to the man pages CLOCK_REALTIME, CLOCK_MONOTONIC,
>     > CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID are supported on
>     > "sufficiently recent versions of glibc and the Linux kernel". I am
>     > running the latest Ubuntu which includes 2.6.28 so I would assume that
>     > this is sufficient.
>    
>      like I said earlier, the latest stable Debian does not install the
>      686-enabled libc automatically. Quite probably true about Ubuntu too.
>    
>      Anyways, here's the test(found by greping in erts/configure).
>    
>            #include <stdlib.h>
>            #include <unistd.h>
>            #include <string.h>
>            #include <stdio.h>
>            #include <time.h>
>            int main() {
>                long long start, stop;
>                int i;
>                struct timespec tp;
>    
>                if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp) < 0)
>                  exit(1);
>                start = ((long long)tp.tv_sec * 1000000000LL) + (long
>                  long)tp.tv_ns$
>                for (i = 0; i < 100; i++)
>                  clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &tp);
>                stop = ((long long)tp.tv_sec * 1000000000LL) + (long
>                  long)tp.tv_nse$
>                if (start == 0)
>                  exit(4);
>                if (start == stop)
>                  exit(5);
>                exit(0); return 0;
>              }
>    
>     >
>     > mats cronqvist wrote:
>     >> Joe Williams <joe@REDACTED> writes:
>     >>
>     >>
>     >>> I am seeing issues with this as well. I have some C++ code that uses
>     >>> clock_gettime and it compiles and seems to work properly. But when I
>     >>> configure Erlang it complains of it being unstable.
>     >>>
>     >>
>     >>   IIRC, it's not the existence of clock_gettime that is the problem,
>     >>   but which clk_ids it supports. Perhaps CLOCK_PROCESS_CPUTIME_ID.
>     >>
>     >>   mats
>     >>
>     >>
>     >>> mats cronqvist wrote:
>     >>>
>     >>>> Adam Kocoloski <adam.kocoloski@REDACTED> writes:
>     >>>>
>     >>>>
>     >>>>
>     >>>>> Hi, it seems to me that cpu_timestamp tracing is automatically
>     >>>>> disabled on Linux.  configure spits out
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>> checking if clock_gettime can be used to get process CPU
>     >>>>>> time... not  stable, disabled
>     >>>>>>
>     >>>>>>
>     >>>>> and in aclocal.m4 I see
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>> case $host_os in
>     >>>>>>  linux*)
>     >>>>>>          AC_MSG_RESULT([not stable, disabled])
>     >>>>>>          LIBRT=$xrtlib
>     >>>>>>          ;;
>     >>>>>>  *)
>     >>>>>>
>     >>>>>>
>     >>>>> I'm wondering what the rationale was behind that, and in particular
>     >>>>> whether newer kernels might have fixed the problem.  Does anyone
>     >>>>> around here know a little more of the backstory? Best,
>     >>>>>
>     >>>>>
>     >>>>   I'm not really familiar with this, so the following is at best
>     partly
>     >>>>   right.
>     >>>>
>     >>>>   configure checks for a syscall;
>     >>>> http://www.linuxhowtos.org/manpages/2/clock_gettime.htm
>     >>>>
>     >>>>   On linuxen, this needs support from hardware, the kernel and libc.
>     >>>>
>     >>>>   E.g. on debian, with a 2.6 kernel, on i686 HW, you need to install
>     >>>>   libc6-i686. That will give you a variant of clock_gettime that is
>     >>>>   deemed "stable" by configure.
>     >>>>
>     >>>>   mats
>     >>>> _______________________________________________
>     >>>> erlang-questions mailing list
>     >>>> erlang-questions@REDACTED
>     >>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>     >>>>
>     >>>>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED
>     http://www.erlang.org/mailman/listinfo/erlang-questions