From: Tanaka Akira <akr@...>
Date: 2013-07-26T12:42:13+09:00
Subject: [ruby-core:56190] Re: [ruby-trunk - Feature #8658] Process.clock_gettime

2013/7/24 Eregon (Benoit Daloze) <redmine@ruby-lang.org>:
> Issue #8658 has been updated by Eregon (Benoit Daloze).
>
> A very poor one as mapping to Linux/UNIX constants would just confuse people.
> I do not think the UNIX API clock_gettime() for this is the most suitable,
> it does not abstract the functionality and the name/usage is not very ruby-like.

If constants defined by Unix is not suitable, original constants can be defined.

Ruby uses POSIX functions in general.
So I think clock_gettime is very Ruby-ish (and I guess it is easier
than original design
to persuade matz).

> I think FFI would be a good way if someone need direct access to that low-level C function (except for accessing the constants, that would not be handy).

How FFI can be used to call clock_gettime?
I don't have experience with FFI.

> I believe providing a method which is only available in a quite restricted set of platforms is to be avoided.
> In Python it is simply not defined on non-supporting platforms.

At least, CLOCK_REALTIME can be emulated on all platforms.
Other clocks may be too, on some platforms.

Also, Ruby provides many platform dependent methods in Process.

>>  Higer level methods may be useful but what I intend in this issue is a
>>  low level primitive.
>
> To which use-cases other than benchmarking do you think?

I expect that I use CLOCK_PROCESS_CPUTIME_ID.

> I want Ruby to propose a nice and precise way to benchmark code *not* requiring the user to know about every detail of available clocks/timers under every platform.

It is good to have such high level methods but
it doesn't conflict with low level methods.
-- 
Tanaka Akira