Mocking Process.clock_gettime causes Concurrent::IVar with timeout to wait indefinitely

[olly]

Updating Timecop to v0.9.9 caused some of our system integration tests which utilise frozen time to wait indefinitely. I managed to narrow it down to the change introduced in 3a0b567.

We initially noticed it in a system integration test which used capybara & cuprite to drive a browser. However on further investigation I believe the root cause it down to ferrum's use of a Concurrent::IVar.

I've created a minimal test case which can reproduce the issue.

It appears the concurrent-ruby uses monotonic time to determine whether a timeout has been passed, and therefore by stubbing the monotonic clock it never causes a timeout.

---

I'm not sure what the exact resolution of this should be. I can see the value in being able to stub the monotonic clock, but perhaps it's too low level to stub by default? I imagine if this impacts a number of concurrent-ruby data structures then it might cause Timecop to be unusable in a large number of testing scenarios.

---

Thanks for all your hard-work on this gem. ❤️

[nerdrew]

Can we make stubbing Process.clock_gettime a configurable option when freeze-ing or travel-ing?

[joshuacronemeyer]

@alexcwatt any chance you can look at this? I think @nerdrew's suggestion is one viable option. Should we make this option disabled by default? Interested in opinions on this.

[joshuacronemeyer]

thanks @olly for raising this issue. i'm hopeful we can have a solution and get a 0.9.10 release out quickly

[alexcwatt]

@joshuacronemeyer 👀 will take a look

[alexcwatt]

@olly Thanks again for flagging. I cloned your gist, changed Ruby version to 3.2.1 (that's what I have on this MacBook), and was able to repro the issue. Then I upgraded timecop to 0.9.10 and validated the fix - the test doesn't hang.

@joshuacronemeyer I can't close this but based on validation it seems safe to close, and let @olly reopen if there is something we've missed here.