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

71–80 of 129 posts

Re: setBigTimeout

#71

Post by asveikau »

drdaeman wrote: post #37
arp242 wrote: post #28

Earlier quoted context omitted.

You're correct about JS numbers. It works like this presumably because the implementation is written in C++ or the like and uses an int32 for this, because "25 days ought to be enough for everyone".

I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.

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.

Re: setBigTimeout

#72

Post by userbinator »

n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

I always try to force the timeout to 0 on those really annoying download sites that try to make me wait.

Sometimes the wait is over before I find the responsible code, and sometimes it does check server-side, but that's just part of the fun...

Re: setBigTimeout

#73

Post by ashkankiani »

swatcoder wrote: post #31
n2d4 wrote: post #10

The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…

That's just terrible input validation and has nothing to do with setTimeout. If your code would misbehave outside a certain range of values and you're input might span a larger range, 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. That the bug happens to involve a timer is irrelevant.

You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.

Re: setBigTimeout

#74

Post by ajkjk »

internetter wrote: post #69
Joker_vD wrote: post #44

Earlier quoted context omitted.

One has still to know that "tree" stands for "source code".

This is not a sourcehut problem, it is a github problem. "Tree" is semantically correct.

What? Of course it's a Sourcehut problem. They chose to use that word and could choose to use a better one.

Re: setBigTimeout

#75

Post by log_e »

ashkankiani wrote: post #73
swatcoder wrote: post #31

Earlier quoted context omitted.

That's just terrible input validation and has nothing to do with setTimeout. If your code would misbehave outside a certain range of values and you're input might span a larger range, 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. That the bug happens to involve a timer is irrelevant.

You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.

It's in the standard library. You're a bad programmer if you don't learn the ins and outs of the standard library, or make sweeping generalizations.

Re: setBigTimeout

#76

Post by zeroonetwothree »

ballenf wrote: post #46
yifanl wrote: post #7

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.

Each subtracted timeout is a 25 day timer, so any accumulated error would be miniscule. In your example there would a total of 2 setTimeouts called, one 25 day timer and one 15 day. I think the room for error with this approach is smaller and much simpler than calculating the date delta and trying to take into account daylight savings, leap days, etc. (but I don't know what setTimeout does with those either). Or mayb…

You don’t need to take into account daylight savings or leap days when dealing with unixtime.

Re: setBigTimeout

#77

Post by chii »

jw1224 wrote: post #57
darepublic wrote: post #30

instead of chaining together shorter timeouts, why not calculate the datetime of the delay and then invoke via window.requestAnimationFrame (by checking the current date ofc).

Unlike setTimeout, requestAnimationFrame callbacks are automatically skipped if the browser viewport is minimized or no longer visible. You wouldn’t want to miss the frame that matters!

also, not to mention that setBigTimeout would still work in serverside js, while requestanimationframe doesn't!

Re: setBigTimeout

#78

Post by kelnos »

asveikau wrote: post #71
drdaeman wrote: post #37

Earlier quoted context omitted.

I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.

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.

Re: setBigTimeout

#79

Post by kelnos »

Joker_vD wrote: post #44
egwynn wrote: post #25

Earlier quoted context omitted.

I agree it’s not the prettiest, but I had no trouble clicking on “tree” to get to the folder and then “mod.ts” to see the code.

One has still to know that "tree" stands for "source code".

That seems like... a normal thing to know?

Pre-GitHub, one of the most popular web git viewers (cgit) used "tree" in this way. Never found that to be confusing.

(In git, the listing of the files and directories at a particular commit is called a "tree". So it's correct. Just not as intuitive as you, personally, would like.)

Re: setBigTimeout

#80

Post by keepamovin »

Aachen wrote: post #55
keithwhor wrote: post #41

Earlier quoted context omitted.

Oh yikes. Yeah; not ideal.

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 sh…

I guess the dream of programming the next heliopause probe in JavaScript is still a ways off hahaha! :)
Post reply on HN