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

mats cronqvist masse@REDACTED
Thu May 14 10:47:52 CEST 2009


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
>>>>   
>>>>       



More information about the erlang-questions mailing list