si-timers: round difftime to microseconds in IOSim

[coot]

This makes threadDelay from si-timers sublibrary behave the same way
for IOSim and IO.

[Copilot]

Pull Request Overview

This PR introduces a new function roundDiffTimeToMicroseconds to round DiffTime values down to microsecond precision and uses it in the SI.MonadDelay instance for IOSim. This ensures that thread delays in the SI timer interface have consistent microsecond granularity without fractional microseconds.

• Added roundDiffTimeToMicroseconds function to round DiffTime to microseconds
• Updated SI.MonadDelay instance to use rounding instead of passing through the original DiffTime
• Added property tests to verify the rounding behavior

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
io-classes/si-timers/src/Control/Monad/Class/MonadTimer/SI.hs	Implements roundDiffTimeToMicroseconds function that rounds down to microsecond precision
io-sim/src/Control/Monad/IOSim/Types.hs	Updates SI.MonadDelay instance to apply microsecond rounding to thread delays
io-classes/si-timers/test/Test/MonadTimer.hs	Adds property tests for the new rounding function

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nfrisby]

Suggested a possible alternative

[nfrisby]

Does threadDelay x for x<0 have a different behavior than threadDelay 0?

If not, then this comment seems like a distraction.

[coot]

threadDelay doesn't, but timeout does, I am not sure about registerDelay, probably not, I'll check.

[nfrisby]

Evaluate the rounding calculation strictly?

[nfrisby]

The same question applies several other places in this diff.

[nfrisby]

Instead of leaving the type as more generous than the canonical implementation's (ie IO), what do you think about instead adding a bespoke newtype?

import Data.Fixed (Micro)

newtype DiffTimeRoundedToMicroseconds = DiffTimeRoundedToMicroseconds Micro
   deriving (...?)

roundDiffTimeToMicroseconds :: DiffTime -> DiffTimeRoundedToMicroseconds

forgetDiffTimeToMicroseconds :: DiffTimeRoundedToMicroseconds -> DiffTime

This would make everything very explicit.

The disadvantage is that people would sometimes be forced to call roundDiffTimeToMicroseconds even when they were certain their DiffTime's internal Pico was already a whole number multiple of 1e6.

[coot]

If we change the API in si-timers and IOSim to use DiffTimeRoundedTOMicroseconds it will have massive consequences in ouroboros-newtork. The cost of changing it might be too big.

The question is, how surprised will one be with threadDelay 0.000_000_1s only to yield the current thread for 0s: it will put it in the back of the scheduler's queue, instead of executing it in another time slot - this could be a bit surprising.

threadDelay negativeDelay doesn't yield a thread, but rounding doesn't change non-negative numbers into negative ones, so no surprises in this case :).

[coot]

	solution	conseqences
1.	DiffTimeRoundedToMicroseconds	breaking API, but no surprises
2.	implicit rounding	surprises in IOSim, but no surprises when compared to IO
3.	the current situation	no surprises in IOSim, but different semantics than IO

My pick would be: 1. long-term, 2. or 3. short-term.