A backend for Ruby >= 2.1 using Process.clock_gettime

[eregon]

Since Ruby 2.1, there is Process.clock_gettime(Process::CLOCK_MONOTONIC, :nanosecond).
This uses the appropriate syscall based on the platform.

If hitimes would use this on Ruby >= 2.1, I think no C or JRuby extension would be needed, and there would be no need to access macOS frameworks.

The issue was initially reported in oracle/truffleruby#1436, where TruffleRuby does not support -framework yet. It probably could, but it seems better to use a core method when available rather than re-implementing it with a C extension.

Do you want to keep supporting Ruby 2.0?
If not, then the whole C/JRuby extensions could likely go away altogether, but that would also mean every gem depending on hitimes must drop Ruby <= 2.0 support too.

@copiousfreetime What do you think?

[copiousfreetime]

@eregon I had this as a todo for a long time (see #22) and after digging into it last year it looked ruby natively doesn't support the nanosecond resolution on at least OSX even though it could.

And after reviewing the code I was looking at last summer...It appears I was looking at the wrong bits of the ruby source code. I did a better review just now - and it looks like that ruby's Process.clock_gettime will work. So - should be doable to make hitimes pure ruby. i'd also end up removing the stats calculations - as those are in C also.

I'll play around with some things and see what comes out. In any case - this would probably end up with a major version bump just to cover the < Ruby 2.1 deprecation.

[eregon]

Sounds good. I searched for Process.clock_gettime before filing an issue but found nothing.

FWIW, I found out recent macOS also supports clock_gettime(2) directly.

One way to already use Process.clock_gettime in hitimes 1.x would be to keep the extensions as fallback for Ruby < 2.1 for a single 1.x release. And then a 2.0 release would then drop Ruby < 2.1 compatibility. The advantage is every dependency using hitimes 1.x on Ruby >= 2.1 would then use core Ruby features.

[ioquatix]

Just FYI, I moved to using Process.clock_gettime in async and timers so that is no longer a major dependency (of course old versions still are). It was a point release for timers. So I believe most users can update.

So, @copiousfreetime your offer to update the gem is awesome, but if you have other things to spend your time on that are more valuable to you, it's no longer a dependency of timers.

Thanks so much for this gem and all your work.

[copiousfreetime]

Almost completed extension removal over in #73

[eregon]

This looks great!

[copiousfreetime]

@eregon well - my pure ruby version also doesn't work on truffleruby 😂 - I've sent a pull request over to truffle ruby - oracle/truffleruby#1594 - not sure if that's the right way to go or not - all feedback welcome.

[eregon]

@copiousfreetime Great 😃

I also commented on the PR #73. Did Hitimes provide clock resolution before?

[copiousfreetime]

Version 2.0.0 pushed with no C extension

[eregon]

Thanks a lot!