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

[Roger Critchlow]

Maybe I'm confused, but I think the problem is that configure ignores the
test result under 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090514/fcc6db0a/attachment.htm>