-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: Duplex autoDestroy with disabled readable/writable #32139
Conversation
This requires another @nodejs/tsc review |
@jasnell: This might be of interested to you in relation to the quic work. |
I have no specific objection but I think we should not change the behavior of a generic base class to make it work like one of its derived class. |
Though I would argue that this behavior makes sense... regardless where it's based from? |
@mcollina Do you approve this? I don't usually approve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would need to know more about this change? Can you enrich the description a little bit? It seems very subtle.
I'm especially worried that for a semver-major change we only have so little tests. I would like to ask for a test that covers this behavior.
Yea, I totally missed the tests. Sorry about that. I'll sort this out. |
@mcollina: I have updated the description. Please take a look and let me know if it makes sense. I'll make some proper tests if you find it sensible. |
Please also see the comment here https://github.com/nodejs/node/pull/32158/files#diff-009356850b536cab27b019ba8ad15e72R87-R88 |
I'm good with this change, although with quic we cannot use autoDestroy as the lifecycle of the object is not tied only to the writable/readable state. |
This comment has been minimized.
This comment has been minimized.
@nodejs/streams This PR also fixes the following comment: https://github.com/nodejs/node/pull/32158/files#diff-009356850b536cab27b019ba8ad15e72R86-R92 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a few tests for the change in behavior?
stream.Duplex and net.Socket slightly differs in behavior. Especially when it comes to the case where one side never becomes readable or writable. This aligns Duplex with the behavior of Socket.
rebased and added tests |
2696a6e
to
fdd369c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
stream.Duplex and net.Socket slightly differs in behavior. Especially when it comes to the case where one side never becomes readable or writable. This aligns Duplex with the behavior of Socket. PR-URL: #32139 Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in 388cef6 |
stream.Duplex and net.Socket slightly differs in behavior.
Especially when it comes to the case where one side never
becomes readable or writable. This aligns Duplex with the
behavior of Socket.
The "trick"
net.Socket
does is to explicitly setwritable
/readable
tofalse
instead of callingend()
/push(null)
to avoid the'finish'
/'end'
events.This PR extract the streams part of #31806 for easier review.
---- EDIT UPDATED DESCRIPTION ----
Some streams are implemented as
Duplex
but don't know whether they are unidirectional or not until runtime. In the case that it is determined as unidirectional then one of the sides need to be disabled for e.g.autoDestroy
,stream.finished
to work properly. However, it doesn't make sense to callend()/push(null)
since it never werewritable/readable
and emitting'finish'/'close'
is weird/confusing.They way e.g.
net.Socket
resolves it (and maybe quic and other implementors might want to resolve it? @jasnell) is to explicitly setwritable/readable
tofalse
once/if it has determined the stream to be unidirectional. This works already, however it would breakautoDestroy
which (before this PR) waits for both sides to complete, when (in this case) only one is expected complete.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes