Skip to content
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

Closed
scottinet opened this issue Feb 6, 2017 · 8 comments
Closed

Expose arbitrary constants like TIMEOUT_MAX #11198

scottinet opened this issue Feb 6, 2017 · 8 comments
Labels
question Issues that look for answers. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.

Comments

@scottinet
Copy link

scottinet commented Feb 6, 2017

  • 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.

@claudiorodriguez
Copy link
Contributor

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
Copy link
Contributor

mscdex commented 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 as long, which is likely to be 32-bit (at least for historical reasons because setTimeout(), etc. existed before 64-bit computers became widespread, although some compilers on 64-bit still make long 32-bit).

With that said, I'm not sure if there is any real benefit to exporting this maximum.

@mscdex mscdex added question Issues that look for answers. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. labels Feb 6, 2017
@cjihrig
Copy link
Contributor

cjihrig commented 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
Copy link
Member

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

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
Copy link
Member

After mulling it over I think I'm -0.5 on exposing the limit. Browsers don't either.

@scottinet
Copy link
Author

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
Copy link
Member

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
Copy link
Member

Trott commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Issues that look for answers. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout.
Projects
None yet
Development

No branches or pull requests

6 participants