★ wanayoo — archive 1999 https://github.com/nodejs/node/pull/18098Nouvelle recherche | Portail wanayoo
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

stream: check type and range of highWaterMark #18098

Closed
wants to merge 7 commits into from

Conversation

tniessen
Copy link
Member

@tniessen tniessen commented Jan 11, 2018

Continuation of #13065.

Stream constructors should throw when an invalid highWaterMark option is given.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

stream

tniessen added 2 commits Jan 11, 2018
The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.
@tniessen
Copy link
Member Author

@tniessen tniessen commented Jan 11, 2018

There are two aspects which I would like to discuss:

  1. NaN is accepted but ignored. This is the expected behavior according to test-stream-transform-split-highwatermark, but I don't see much value in that.
  2. Floating point numbers are permitted and rounded to integers.

@mcollina
Copy link
Member

@mcollina mcollina commented Jan 11, 2018

I'm 👍 in removing support for NaN, i.e. throwing if it is passed.
I would keep the rounding, as it might happen that highWaterMark  is the result of some division, and I don't think the rounding harms

Copy link
Member

@BridgeAR BridgeAR left a comment

I suggest to implement this in a more efficient way.

I also agree with @mcollina that NaN should not be supported anymore.

LGTM otherwise!


// Default value
return state.objectMode ? 16 : 16 * 1024;
}
Copy link
Member

@BridgeAR BridgeAR Jan 11, 2018 •

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following should be more efficient (untested):

function getHighWaterMark (options, isDuplex, specialKey, objectMode) {
  if (typeof options.highWaterMark === 'number') {
    if (options.highWaterMark < 0 || Number.isNaN(options.highWaterMark)) {
      throw new errors.TypeError(
        'ERR_INVALID_OPT_VALUE',
        'options.highWaterMark',
        options.highWaterMark
      )
    }
    return Math.floor(options.highWaterMark)
  }
  if (isDuplex) {
    if (typeof options[specialKey] === 'number') {
      if (options[specialKey] < 0 || Number.isNaN(options[specialKey])) {
        throw new TypeError(...)
      }
      return Math.floor(options[specialKey])
    }
    if (options[specialKey]) {
      throw new TypeError(...)
    }
  } else if(options.highWaterMark) {
    throw new TypeError(...)
  }

  return objectMode ? 16 : 16 * 1024
}

getHighWaterMark(
  options,
  isDuplex,
  'writableHighWaterMark', // Replace accordingly
  this.objectMode
)

Copy link
Member Author

@tniessen tniessen Jan 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was going to extract the key anyway, just wanted to hear opinions about NaN first (that really annoyed me).

Copy link
Member Author

@tniessen tniessen Jan 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, !(options.highWaterMark >= 0) should be faster than options.highWaterMark < 0 || Number.isNaN(options.highWaterMark).

Copy link
Member

@BridgeAR BridgeAR Jan 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is probably true.

Copy link
Member

@mcollina mcollina left a comment

LGTM

@mcollina mcollina requested review from jasnell and addaleax Jan 11, 2018
@tniessen tniessen added this to the 10.0.0 milestone Jan 11, 2018
@BridgeAR BridgeAR requested a review from Jan 14, 2018
targos
targos approved these changes Jan 14, 2018
@mcollina
Copy link
Member

@mcollina mcollina commented Jan 18, 2018

This needs a CITGM before landing run after #18210 lands and we get CITGM back.

@tniessen
Copy link
Member Author

@tniessen tniessen commented Jan 22, 2018

@tniessen
Copy link
Member Author

@tniessen tniessen commented Jan 22, 2018

citgm looks good to me, can someone confirm?

@addaleax
Copy link
Member

@addaleax addaleax commented Jan 22, 2018

@tniessen yup, looks good to me too 👍

@tniessen
Copy link
Member Author

@tniessen tniessen commented Jan 22, 2018 •

tniessen added a commit that referenced this issue Jan 29, 2018
The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.

PR-URL: #18098
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@tniessen
Copy link
Member Author

@tniessen tniessen commented Jan 29, 2018

Landed in 46e0a55.

@tniessen tniessen closed this Jan 29, 2018
MayaLekova added a commit to MayaLekova/node that referenced this issue May 8, 2018
The (h|readableH|writableH)ighWaterMark options should only permit
positive numbers and zero.

PR-URL: nodejs#18098
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants