Keep a private reference to Process.clock_gettime

[casperisfine]

timeout 0.3.0 broke our test suite because we have some tests that stubs Process.clock_gettime making it return a value in the past, causing Timeout to trigger almost immediately.

I believe it wasn't a problem before because it was relying on Process.sleep.

cc @eregon what do you think? I agree this one is debatable, as if you are messing with time primitive you're on your own, but it's a common thing to do in tests suites with tools such as Timecop.

[eregon]

The fix seems reasonable.
I wonder if it's reasonable for Timecop to monkey patch clock_gettime though (especially with CLOCK_MONOTONIC), that seems likely to break far more things than just this. Shouldn't it only use a fixed instant for Time and Date/DateTime and leave the rest alone?

[casperisfine]

Note that I said Timecop, but it actually doesn't do it (travisjeffery/timecop#220), it was a "manual" mocha stub.

Shouldn't it only use a fixed instant for Time and Date/DateTime and leave the rest alone?

Well, as long as some code Process.clock_gettime, you sometimes need to stub it to simulate some cases. timeout just happens to be a bit problematic.

that seems likely to break far more things than just this.

These tests are old, and AFAIK that's the first time they break. But yes, we could probably also cleanup our code and have a small indirection we could stub instead. If you're unconfortable with this change, I'm fine with closing. I mostly thought it was worthy of discussion, not necessarily of merging.

[jjb]

drawback of this is that if someone wants to stub Process.clock_gettime in order to test that something does time out, i think it won't work anymore 😄 i was not doing that but go excited when i saw this code because i might want to