←back to thread

setBigTimeout

(evanhahn.com)
210 points cfj | 1 comments | 17 Oct 24 18:01 UTC | HN request time: 0.203s | 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 #
keithwhor ◴[18 Oct 24 18:45 UTC] No.41882294[source]▶
Oh yikes. Yeah; not ideal.
replies(2): >>41883921 #>>41888122 #
1. 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.