| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
/cc @nodejs/streams |
Sorry, something went wrong.
Sorry, something went wrong.
|
Well, CI has failed due to my test... I'm not sure how to handle tty stdin on CI, as it works fine locally. It seems to close the stdin even before the setTimeout fires, can someone help? Should I fork a process for this test and only connect stderr to pass the error? |
Sorry, something went wrong.
There was a problem hiding this comment.
When reading the description of the test it seems like these should be .on instead of once?
Sorry, something went wrong.
There was a problem hiding this comment.
Typo in the.
Sorry, something went wrong.
There was a problem hiding this comment.
If you want to actually test a tty you have to move the test in the corresponding tty test folder. Otherwise it's not detected as try.
Sorry, something went wrong.
|
@BridgeAR thanks a lot, I've missed that. Should be fixed now. |
Sorry, something went wrong.
There was a problem hiding this comment.
Should this not also just be on?
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks, idk why did I think it was okay to put once on both of them. 🤔
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
code LGTM. Can land if citgm does not report additional breakage.
Sorry, something went wrong.
|
Seems good, but CITGM is currently not very healthy: nodejs/build#1429. |
Sorry, something went wrong.
|
I'm not I understand why this is needed for TTYs to work? Can someone clarify this for me? The unneeded readables was breaking of code for me, and as I understand this, it restores that behaivor? |
Sorry, something went wrong.
|
@mafintosh After your comment, I went to double check and found a better way of tackling this problem. But I also discovered the other thing. Your PR is indeed fixing the issue of empty-readable but the thing is, it suppresses the issue by not emitting the event but there are still multiple calls to emitReadable_ present. I tried to actually resolve the issue but to no avail, unfortunately. Here is the description, maybe someone can figure it out. The thing is that with the write pattern as in test/parallel/test-stream-readable-no-unneeded-readable.js triggers 'readable' event upon push (as it should) but due to the fact that it only arrives on the nextTick that .once('readable') manages to catch old readable event (because we have already read all of the data of that event in the wrapper) that is now empty and results in empty (and multiple) 'readable' events. STREAM 15878: do read wrapper read called STREAM 15878: read undefined STREAM 15878: need readable true STREAM 15878: length less than watermark true STREAM 15878: do read wrapper read called STREAM 15878: read undefined STREAM 15878: need readable true STREAM 15878: length less than watermark true STREAM 15878: do read STREAM 15878: on readable 0 true STREAM 15878: read undefined STREAM 15878: need readable true STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: emit readable rStream STREAM 15878: flow null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: need readable false STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: emit readable rStream STREAM 15878: flow null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: need readable false STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: readableAddChunk null STREAM 15878: emit readable rStream readable called STREAM 15878: read undefined STREAM 15878: endReadable false STREAM 15878: flow null STREAM 15878: endReadableNT false 0 STREAM 15878: readableAddChunk null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: endReadable false STREAM 15878: endReadableNT false 0 STREAM 15878: do read STREAM 15878: readableAddChunk <Buffer 62 61 72> STREAM 15878: emitReadable null STREAM 15878: readableAddChunk <Buffer 62 61 72> STREAM 15878: emitReadable true STREAM 15878: read undefined STREAM 15878: need readable false STREAM 15878: length less than watermark true STREAM 15878: do read wrapper read called STREAM 15878: read undefined STREAM 15878: need readable true STREAM 15878: length less than watermark true STREAM 15878: do read STREAM 15878: on readable 0 true STREAM 15878: read undefined STREAM 15878: need readable true STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: emit readable rStream STREAM 15878: flow null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: need readable false STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: emit readable rStream STREAM 15878: flow null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: need readable false STREAM 15878: length less than watermark true STREAM 15878: reading or ended false STREAM 15878: readableAddChunk null STREAM 15878: emit readable rStream readable called STREAM 15878: read undefined STREAM 15878: endReadable false STREAM 15878: flow null STREAM 15878: endReadableNT false 0 STREAM 15878: readableAddChunk null STREAM 15878: emit readable wrapperStream STREAM 15878: flow true STREAM 15878: read undefined STREAM 15878: endReadable false STREAM 15878: endReadableNT false 0 there are 2 more 'emit readable rStream' that were suppressed and I think at least the second one shouldn't have happened at all (the first one is from the latest data push). |
Sorry, something went wrong.
|
@mcollina @mafintosh @BridgeAR I'd like another review as I changed this PR's idea. |
Sorry, something went wrong.
There was a problem hiding this comment.
Can you add some tests that shows the changed behavior in streams? I'd like to see a a test that failed in current master but passes here.
I think we would need to add some docs for highWaterMark: 0. There aren't any atm.
(Using the big red cross because I approved it in the past)
Sorry, something went wrong.
There was a problem hiding this comment.
We'll need to adjust this comment.
Sorry, something went wrong.
There was a problem hiding this comment.
this comment will need an update.
Sorry, something went wrong.
|
It's not really clear what it is changing here. Can you describe it the change to streams a bit more? |
Sorry, something went wrong.
Avoid trying to emit 'readable' due to the fact that
state.length is always >= state.highWaterMark if highWaterMark is 0.
Therefore upon .read(0) call (through .on('readable')) stream assumed
that it has enough data to emit 'readable' even though
state.length === 0 instead of issuing _read(). Which led to the TTY
not recognizing that someone is waiting for the input.
Fixes: nodejs#20503
Refs: nodejs#18372
|
@mcollina cleaned up the PR (and removed redundant checks) and added relevant test without the TTY. Yeah, this shouldn't change anything, it's a bug fix, bad wording, sorry. I've updated the description. P.s. Streams sure are tough, thanks for bearing with me. |
Sorry, something went wrong.
Sorry, something went wrong.
Thanks for taking these issue, they are indeed! |
Sorry, something went wrong.
|
Very nice fix in the end |
Sorry, something went wrong.
|
Thanks @lundibundi for tackling this one! |
Sorry, something went wrong.
Avoid trying to emit 'readable' due to the fact that
state.length is always >= state.highWaterMark if highWaterMark is 0.
Therefore upon .read(0) call (through .on('readable')) stream assumed
that it has enough data to emit 'readable' even though
state.length === 0 instead of issuing _read(). Which led to the TTY
not recognizing that someone is waiting for the input.
Fixes: #20503
Refs: #18372
PR-URL: #21690
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Avoid trying to emit 'readable' due to the fact that
state.length is always >= state.highWaterMark if highWaterMark is 0.
Therefore upon .read(0) call (through .on('readable')) stream assumed
that it has enough data to emit 'readable' even though
state.length === 0 instead of issuing _read(). Which led to the TTY
not recognizing that someone is waiting for the input.
Fixes: #20503
Refs: #18372
PR-URL: #21690
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Avoid trying to emit 'readable' due to the fact that
state.length is always >= state.highWaterMark if highWaterMark is 0.
Therefore upon .read(0) call (through .on('readable')) stream assumed
that it has enough data to emit 'readable' even though
state.length === 0 instead of issuing _read(). Which led to the TTY
not recognizing that someone is waiting for the input.
Fixes: nodejs/node#20503
Refs: nodejs/node#18372
PR-URL: nodejs/node#21690
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
| Back | FazBrowse Home | New Git URL |
Avoid trying to emit 'readable' due to the fact that
state.length is always >= state.highWaterMark if highWaterMark is 0.
Therefore upon .read(0) call (through .on('readable')) stream assumed
that it has enough data to emit 'readable' even though
state.length === 0 instead of issuing _read(). Which led to the TTY
not recognizing that someone is waiting for the input.
Fixes: #20503
Refs: #18372
Checklist
I put one test under sequential as it uses process.stdin to emulate the use case and I'm not sure if that is correct.
Edit: I've changed the PR title and description according to changes.