←back to thread

setBigTimeout

(evanhahn.com)
210 points cfj | 4 comments | 17 Oct 24 18:01 UTC | HN request time: 1.465s | source
Show context
yifanl ◴[18 Oct 24 16:21 UTC] No.41880869[source]▶
If we're pedantic, this doesn't actually do what's advertised, this would be waiting X timeouts worth of event cycles rather than just the one for a true Big timeout, assuming the precision matters when you're stalling a function for 40 days.
replies(3): >>41880887 #>>41882515 #>>41890330 #
keithwhor ◴[18 Oct 24 16:23 UTC] No.41880887[source]▶
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.
replies(2): >>41880912 #>>41882760 #
yifanl ◴[18 Oct 24 16:25 UTC] No.41880912[source]▶
No, it pretty much just does exactly that.

    const subtractNextDelay = () => {
      if (typeof remainingDelay === "number") {
        remainingDelay -= MAX_REAL_DELAY;
      } else {
        remainingDelay -= BigInt(MAX_REAL_DELAY);
      }
    };
replies(1): >>41882294 #
1. keithwhor ◴[18 Oct 24 18:45 UTC] No.41882294[source]▶
Oh yikes. Yeah; not ideal.
replies(2): >>41883921 #>>41888122 #
2. Aachen ◴[18 Oct 24 22:05 UTC] No.41883921[source]▶
To be fair, this is what I expect of any delay function. If it needs to be precise to the millisecond, especially when scheduled hours or days ahead, I'd default to doing a sleep until shortly before (ballpark: 98% of the full time span) and then a smaller sleep for the remaining time, or even a busy wait for the last bit if it needs to be sub-millisecond accurate

I've had too many sleep functions not work as they should to still rely on this, especially on mobile devices and webpages where background power consumption is a concern. It doesn't excuse new bad implementations but it's also not exactly surprising

replies(1): >>41885524 #
3. keepamovin ◴[19 Oct 24 03:52 UTC] No.41885524[source]▶
I guess the dream of programming the next heliopause probe in JavaScript is still a ways off hahaha! :)
4. sulam ◴[19 Oct 24 14:54 UTC] No.41888122[source]▶
But it appears that it is consistent with setTimeout’s behavior and therefore likely correct in the context it will be used.

At least if your definition of “correct” is “does the thing most similar to the thing I’m extending/replicating”. In fact you might believe it’s a bug to do otherwise, and JS (I’m no expert) doesn’t give a way to run off the event loop anyway (in all implementations). Although I’d be amused to see someone running even a 90 day timer in the browser. :)

I’ve think a very precise timeout would want a different name, to distinguish it from setTimeout’s behavior.