Repository navigation
Expose arbitrary constants like TIMEOUT_MAX #11198
Description
- Version: all
- Platform: all
- Subsystem: all
Hi!
Nothing urgent nor critical, but I came across the setTimeout delay limitation to 2^31-1, named TIMEOUT_MAX in timers.js
If I want to handle delays provided by clients potentially larger than that, I have to test it against what appears to be an arbitrary limitation. I have no problem with that. What bothers me is that I have no way to check if this limitation has changed when upgrading nodejs' version, except by hand, and only if I recall that I used it. I'm not really at ease with this. :-)
What would be handy in such cases is to expose this constant (and potentially others?), a bit like what's done in C with limits.h, so that we can use them without wondering if these are subject to future changes.
Activity
claudiorodriguez commentedon Feb 6, 2017
It's not really an arbitrary limitation - it's there because internally it's handled as a 32-bit integer. It doesn't come from node, it comes from v8 IIRC
Does v8 expose these limits? It might not be possible to do what you propose if they're not part of v8's public API.
mscdex commentedon Feb 6, 2017
I don't believe this is related to V8 because timers are not defined by ES specs. The maximum value probably instead came from the HTML spec (which defines
setTimeout()and the like) where the timeout value data type is listed aslong, which is likely to be 32-bit (at least for historical reasons becausesetTimeout(), etc. existed before 64-bit computers became widespread, although some compilers on 64-bit still makelong32-bit).With that said, I'm not sure if there is any real benefit to exporting this maximum.
cjihrig commentedon Feb 6, 2017
I'm in favor of exposing this constant. Any module that deals with timeouts (especially long ones), needs to be aware of this value.
bnoordhuis commentedon Feb 6, 2017
That's basically correct. I imposed the limit because browsers do.
(Close to the truth. The real reason is because someone filed a bug report about it. I generally don't take action until forced to.)
bnoordhuis commentedon Feb 7, 2017
After mulling it over I think I'm -0.5 on exposing the limit. Browsers don't either.
scottinet commentedon Feb 8, 2017
Instead of exposing this constant alone, which I agree is debatable because I do think that it won't fit in the current timer API, I was thinking more about exposing current system & nodejs limitations, such as the maximum number of arguments of a process, the maximum number of files a process can open, the maximum number of bytes in a filename (and in a path), and so on.
bnoordhuis commentedon Feb 8, 2017
That may be more difficult to do accurately than you'd might think.
maximum number of arguments of a process - not always readily obtainable; on some platforms it's a function of the summed length of the arguments
maximum number of files a process can open - available through getrlimit(RLIMIT_NOFILE) but has no real Windows counterpart and on Unices you have that hard limit/soft limit dichotomy; which one do you pick?
the maximum number of bytes in a filename - depends on the file system; some file systems don't have hard limits, don't expose them or calculate them in characters, not bytes
Consider that if it were easy to expose a particular system property in a cross-platform way, then node probably would have done it by now.
Trott commentedon Jul 26, 2017
This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.