-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose arbitrary constants like TIMEOUT_MAX #11198
Comments
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 |
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 With that said, I'm not sure if there is any real benefit to exporting this maximum. |
I'm in favor of exposing this constant. Any module that deals with timeouts (especially long ones), needs to be aware of this value. |
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.) |
After mulling it over I think I'm -0.5 on exposing the limit. Browsers don't either. |
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. |
That may be more difficult to do accurately than you'd might think.
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. |
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. |
Hi!
Nothing urgent nor critical, but I came across the setTimeout delay limitation to 2^31-1, named
TIMEOUT_MAX
in timers.jsIf 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.The text was updated successfully, but these errors were encountered: