(7/20/13 6:39 AM), akr (Akira Tanaka) wrote:
>
> Issue #8658 has been updated by akr (Akira Tanaka).
>
> File clock_gettime-2.patch added
>
> kosaki (Motohiro KOSAKI) wrote:
>> First, Process.times() returns user time and system time and they are process  specific. But Process::CLOCK_MONOTONIC is not per-process time.
>
> Yes.  Users can choose any clock with Process.clock_gettime unlike other proposals (#8640, #8096).
>
> It seems many people use CLOCK_REALTIME to measure a time interval, though.

So, Why do you choice Process.clock_gettime() instead of Time.clock_gettime()?


>> Second, Linux's CLOCK_MONOTONIC_RAW has the same behavior BSD's CLOCK_MONOTONIC. And, an application which measures a performance need to use CLOCK_MONOTONIC_RAW for avoiding ntp confusing. Then, we should do 1) exporse CLOCK_MONOTONIC_RAW or 2)  Process.clock_gettime(Process::CLOCK_MONOTONIC) uses  CLOCK_MONOTONIC_RAW internally.
>
> OS specific CLOCK_* constants can be defined.
> Since Process.clock_gettime is a primitive, exchange clk_id is not a good idea.

Hm. OK.


>> Third, using float is a good ruby convention. If we need to use inter (for precision and performance?), the method should have a precision explanation, likes get_time_nanosecond. I mean, ruby interpreter can't warn nor detect following mistake.
>>
>> a = foo # this is usec
>> b = bar # this is nsec
>> c = a + b
>>
>> then, we should warn by method name verbosely. IMHO.
>
> Hm.  It is acceptable as far as the exact result (number of nanoseconds) can be obtained.
>
> After thinking while, I find Process.clock_gettime(clk_id, unit).
> unit is an optional argument and :nanoseconds specifies the nanoseconds.
> This can help performance on ILP33 because :microseconds with CLOCK_PROCESS_CPUTIME_ID
> will not use Bignum until 1073 seconds after process start up.
>
> I updated the patch.

An optional argument sound good idea.

thanks.