Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

setBigTimeout

evanhahn.com

Post reply on HN
Print view View original

91–100 of 129 posts

Re: setBigTimeout

#91

Post by zeven7 »

n_plus_1_acc wrote: post #88

In response to this, I read the spec of setTimeout, bu I couldn't find the part where implementations may have an upper bound. Can someone more familiär with the specs point me in the right direction?

Adding a comment here to check back later because I'm curious now if someone has the answer. I thought it would be easy to find the answer, but I can't find it either. I figured it would say somewhere a number is converted to an int32, but instead I got to the part where there's a map of active timers[1] with the time stored as a double[2] without seeing a clear loss happening anywhere before that.

[1] https://html.spec.whatwg.org/multipage/timers-and-user-promp...

[2] https://w3c.github.io/hr-time/#dom-domhighrestimestamp

Re: setBigTimeout

#92

Post by gregoriol »

bufferoverflow wrote: post #89

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

I don't think there is any guarantee that setTimeout will run at exactly 1000. Though didn't expect it to run earlier, it definitely could run later.

Re: setBigTimeout

#93

Post by _flux »

gnachman wrote: post #48
keithwhor wrote: post #9

Earlier quoted context omitted.

I haven’t looked at the code but it’s fairly likely the author considered this? eg the new timeout is set based on the delta of Date.now() instead of just subtracting the time from the previous timeout.

That wouldn't very well because Date.now() isn't monotonic.

There is a monotonic time source available in JavaScript, though: https://developer.mozilla.org/en-US/docs/Web/API/Performance...

As I understand it, the precision of such timers has been limited a bit in browsers to mitigate some Spectre attacks (and maybe others), but I imagine it would still be fine for this purpose.

Re: setBigTimeout

#94

Post by _flux »

bufferoverflow wrote: post #89

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

I wonder if your 999ms was measured using wall-clock time or a monotonic time source? I imagine a wee time correction at an inopportune time could make this happen.

Re: setBigTimeout

#95

Post by steve_adams_86 »

bufferoverflow wrote: post #89

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

Why does your unit test need to wait one second? Or are you controlling the system time, but it still had that error?

Re: setBigTimeout

#96

Post by steve_adams_86 »

This makes me love having Go handy. I find working with signals and time based events so much nicer than other languages I use.

This is fun, though. JS is a bucket of weird little details like this.

Re: setBigTimeout

#97

Post by xnorswap »

bufferoverflow wrote: post #89

setTimeout is stranger than you think. We recently had a failed unit test because setTimeout(fn, 1000) triggered at 999ms. That test had ran more than a hundred times before just fine. Till one day it didn't.

setTimeout has no guarantees, and even if it did, your unit tests shouldn't depend on it.

Flaky unit tests are a scourge. The top causes of flaky unit tests in my experience:

    - wall clock time ( and timezones )
    - user time ( and timeouts )
    - network calls
    - local I/O
These are also, generally speaking, a cause of unnecessarily slow unit tests. If your unit test is waiting 1000ms, then it's taking 1000ms longer than it needs to.

If you want to test that your component waits, then mock setTimeout and verify it's called with 1000 as a parameter.

If you want to test how your component waiting interacts with other components, then schedule, without timers, the interactions of effects as a separate test.

Fast reliable unit tests are difficult, but a fast reliable unit test suite is like having a super-power. It's like driving along a windy mountainside road and the difference between one with a small gravel trap and one lined with armco barriers. Even though in both cases you can the safe driving speed may be the same, having the barriers there will give you the confidence to actually go at that speed.

Doing every you can to improve the reliably and speed of your unit test suite will pay off in developer satisfaction. Every time a test suite fails because of a test failing that had nothing to do with the changes under test, a bit more of a resume gets drafted.

Re: setBigTimeout

#98

Post by erinaceousjones »

drdaeman wrote: post #36
tourist2d wrote: post #35

Earlier quoted context omitted.

> That's just terrible input validation and has nothing to do with setTimeout. Except for the fact that this behaviour is surprising. > you should be checking your input against the range that's valid. Your sample code simply doesn't do that, and that's why there's a bug. Indeed, so why doesn't setTimeout internally do that?

> Indeed, so why doesn't setTimeout internally do that? Given that `setTimeout` is a part of JavaScript's ancient reptilian brain, I wouldn't be surprised it doesn't do those checks just because there's some silly compatibility requirement still lingering and no one in the committees is brave enough to make a breaking change. (And then, what should setTimeout do if delay is NaN? Do nothing? Call immediately? Throw an…

I think it's more likely that it's just "undefined behaviour" and up to the implementers of the JavaScript engines. Given that modern browsers do limit and throttle how much you can do with setTimeout in some situations (try to use setTimeout on a page after you've switched to a VR context! More than like 120hz and it'll just.... Not run the timeout anymore, from experience with Chrome).

The browser devs have decided it's acceptable to change the behaviour of setTimeout in some situations.

https://developer.chrome.com/blog/timer-throttling-in-chrome...

Re: setBigTimeout

#99

Post by [deleted] »

lemagedurage wrote: post #82
arghwhat wrote: post #53

Earlier quoted context omitted.

A minimum timing of an individual task is not a useful rate limit. I could schedule a bunch of tasks to happen far into the future but all at once for example. Rate limits are implemented with e.g., token buckets which fill to a limit at a fixed rate. Timed tasks would then on run try to take a token, and if none is present wait for one. This would then be dutifully enforced regardless of the current state of schedul…

I don't think it's that far fetched that a developer implements a rate limiter with setTimeout, where a task can only be executed if a timeout is not already running. The behaviour in the article is definitely a footgun in this scenario.

[deleted]

Re: setBigTimeout

#100

Post by lloeki »

kelnos wrote: post #78
asveikau wrote: post #71

Earlier quoted context omitted.

There's a shocking amount of systems that still have 32 bit time_t. Linux and glibc only started supporting it on 32bit systems in the current decade.

I mean, we still have 14 years to go. It's not like it's 1999 and everyone is freaking out about y2k. We still have plenty of time. That doesn't mean it's fine to wait and leave it until the last minute, but we have quite a few last minutes left at this point.

> we have quite a few last minutes left at this point.

    C’est l’histoire d’un homme qui tombe d’un immeuble de 50 étages.

    Le mec, au fur et à mesure de sa chute, il se répète sans cesse pour se rassurer:
    
    "Jusqu’ici tout va bien."
    "Jusqu’ici tout va bien."
    "Jusqu’ici tout va bien..."

    Mais l’important c’est pas la chute, c’est l’atterrissage.
Tx'd:

    There's this story of a man falling off a 50 floor building. Along his fall the guy repeats to himself in comfort:

    "So far, so good"
    "So far, so good"
    "So far, so good..."

    What matters though is not the fall, but the landing.
- Hubert, in La Haine (1995), Mathieu Kassovitz

https://youtube.com/watch?v=U-v6QVlpReU

Post reply on HN