Hacker News Reader

Comment by londons_explore | Hacker News Reader

It's really hard to use these API's correctly.

Remember... your CPU can halt at any time for any number of milliseconds. That means simple things like:

    upperBound, lowerBound = readTime()
    if (upperBound<deadline)
      do_stuff(x, y, z)

Are incorrect... There is no guarantee that the 'if' statement didn't take many milliseconds, and that the stuff didn't end up happening after the deadline.

It's also very easy to write code that works, but is theoretically wrong. You will leave a hidden bug that may only rear its head years down the line.

View on HN

Yeah, I was thinking about this too. Without a real-time OS on separate hardware, and/or some kind of guaranteed "will not context-switch out of your process for more than X time" + strict coding habits, this seems like at best a practical (>?)99% improvement and at worst snake-oil. Certainly not reliable in any case.

edit: well, after reading Spivak's comment[1] a bit, I guess it does provide strict upper bounds. May be useful to reduce how often you need to use fallback behaviors / get more byzantine. Though I'm not yet sure how to turn that into something useful. No doubt there are some though.

[1] https://news.ycombinator.com/item?id=29103093

Is that really the API? I'm sure I'd be writing:

  lowerBound, upperBound = readTime()

often without noticing my error.

I mean it’s not that hard even on non-rt preemptive schedulers. You can’t avoid false negatives because you could be preempted after func completes but before the time is fetched but if you get a result it will be valid.

    def must_complete_before(func, deadline):
        result = func()
        lower, upper = time.now()
        if upper < deadline:
            return result
        else:
            throw MissedDeadlineException(“Can’t guarantee func completed before deadline”)

Assuming func() doesn’t have side effects, sure. But if the point was to gate func() to only run before deadline this doesn’t really help.

Yeah but that doesn’t have anything to do with this API. If you want to use it that way, obviously the reasoning is defective.

This API is to determine if something that happened at a given instant is definitely in the past. That’s it!

You can use rseq on linux to avoid this.

To be fair your example would be unsafe with and kind of time API.

The APIs provided by TrueTime and Time Sync are useful to compare two events, each with their own uncertainty intervals. Then you can be sure if any event "happened before" the other, or if they're concurrent.

How about just

    syncTime()

And they take care of the mess

Reply on news.ycombinator.com