| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
Can you add some description/comments to the test? It would be more explicit to add some assertions as well.
Sorry, something went wrong.
|
Added simple description. Not sure what assertion would be relevant here? |
Sorry, something went wrong.
There was a problem hiding this comment.
Can you also add a test for file streams specifically, along the lines of the reproduction in the original issue?
Sorry, something went wrong.
Sorry, something went wrong.
|
@nodejs/streams |
Sorry, something went wrong.
Sorry, something went wrong.
|
Test failures look like this: Mismatched noop function calls. Expected exactly 1, actual 0.
at Object.mustCall (/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/common/index.js:337:10)
at Object.<anonymous> (/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/parallel/test-stream-readable-read-max-hwm.js:29:20)
at Module._compile (internal/modules/cjs/loader.js:958:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:994:10)
at Module.load (internal/modules/cjs/loader.js:813:32)
at Function.Module._load (internal/modules/cjs/loader.js:725:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1046:10)
at internal/main/run_main_module.js:17:11 |
Sorry, something went wrong.
|
@Trott: Picking another bufferSize triggered another type of failure. I've partly fixed it but not entirely. So though this fixes the referred issue it doesn't fix every issue. I will need to spend more time on this. |
Sorry, something went wrong.
|
@mcollina @addaleax I think fixing this is basically going to end up with almost identical behaviour as not having a MAX_HWM at all... I'm not sure what the rationale for MAX_HWM was. I need a little guidance on what we would prefer here:
|
Sorry, something went wrong.
|
I would recommend a scavenge in history in why there is a MAX_HWM at all. It would be good to do a git bisect to find out which commit broke this (likely is one of mine), so we would know more. |
Sorry, something went wrong.
|
@mcollina: Thanks. Didn't even consider removing it. Updated PR. |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
MAX_HWM was added in 9208c89 where the highwatermark was changed to always increase in steps of highest power of 2 to prevent increasing hwm excessivly in tiny amounts. Why a limit was added on the highwatermark is unclear but breaks existing usage where a larger read size is used. The invariant for read(n) is that a buffer of size n is always returned. Considering a maximum ceiling on the buffer size breaks this invariant. This PR significantly increases the limit to make it less likely to break the previous invariant and also documents the limit. Fixes: nodejs#29933 PR-URL: nodejs#29938 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
|
@BridgeAR this should probably be backported to node 12? |
Sorry, something went wrong.
MAX_HWM was added in 9208c89 where the highwatermark was changed to always increase in steps of highest power of 2 to prevent increasing hwm excessivly in tiny amounts. Why a limit was added on the highwatermark is unclear but breaks existing usage where a larger read size is used. The invariant for read(n) is that a buffer of size n is always returned. Considering a maximum ceiling on the buffer size breaks this invariant. This PR significantly increases the limit to make it less likely to break the previous invariant and also documents the limit. Fixes: #29933 PR-URL: #29938 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
MAX_HWM was added in 9208c89 where the highwatermark was changed to always increase in steps of highest power of 2 to prevent increasing hwm excessivly in tiny amounts. Why a limit was added on the highwatermark is unclear but breaks existing usage where a larger read size is used. The invariant for read(n) is that a buffer of size n is always returned. Considering a maximum ceiling on the buffer size breaks this invariant. This PR significantly increases the limit to make it less likely to break the previous invariant and also documents the limit. Fixes: #29933 PR-URL: #29938 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
MAX_HWM was added in 9208c89 where the highwatermark was changed to always increase in steps of highest power of 2 to prevent increasing hwm excessivly in tiny amounts. Why a limit was added on the highwatermark is unclear but breaks existing usage where a larger read size is used. The invariant for read(n) is that a buffer of size n is always returned. Considering a maximum ceiling on the buffer size breaks this invariant. This PR significantly increases the limit to make it less likely to break the previous invariant and also documents the limit. Fixes: #29933 PR-URL: #29938 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
MAX_HWM was added in 9208c89 where the highwatermark was changed to always increase in steps of highest power of 2 to prevent increasing hwm excessivly in tiny amounts. Why a limit was added on the highwatermark is unclear but breaks existing usage where a larger read size is used. The invariant for read(n) is that a buffer of size n is always returned. Considering a maximum ceiling on the buffer size breaks this invariant. This PR significantly increases the limit to make it less likely to break the previous invariant and also documents the limit. Fixes: #29933 PR-URL: #29938 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
| Back | FazBrowse Home | New Git URL |
MAX_HWM was added in 9208c89 where the highwatermark was changed to
always increase in steps of highest power of 2 to prevent increasing
hwm excessivly in tiny amounts.
Why a limit was added on the highwatermark is unclear but breaks
existing usage where a larger read size is used. The invariant for
read(n) is that a buffer of size n is always returned. Considering
a maximum ceiling on the buffer size breaks this invariant.
This PR significantly increases the limit to make it less likely to
break the previous invariant and also documents the limit.
Fixes: #29933
Checklist