-
Notifications
You must be signed in to change notification settings - Fork 31.2k
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: deprecate readableFlowing setter #39644
base: main
Are you sure you want to change the base?
Conversation
@nodejs/streams |
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'm -1 to this change. This property is used by Node.js core.
Yes. But probably doesn't need to.
|
I agree! This PR should also take care of those removals. |
What about http_server? |
I agree with @mcollina. If this PR can clean up the existing core uses of the property then I'd be +1 on this PR. I'm -1 on deprecating with removing those existing references. |
Lines 286 to 288 in 967b5db
Lines 376 to 378 in 967b5db
I wonder if they are really needed, and if so, what to use instead? |
b5956e9
to
1a65529
Compare
If the implementations use readable instead of data events they are not required. |
Like this c24df78? |
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 if we are not breaking the ecosystem.
Good work!
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.
Nice!
The However I noticed some performance regressions: Benchmark results (
|
Some definitely related failures in CI that need to be investigated. I removed the |
@Mesteery would you have time to go back to this? v17.0.0 semver cutoff is next week, in case you want this PR to be included. This would need a rebase to fix the git conflict and a passing CI. |
Yes, of course. But currently the solution does not work perfectly, and I have not been able to find a solution that works better. cc @ronag |
@Mesteery any chance you would be able to revive this? |
Yes, of course, but I need help, I don't know the origin of the issue at all and I don't see where it can come from or how to fix it |
|
||
if (req.timeoutCb) socket.removeListener('timeout', req.timeoutCb); | ||
socket.removeListener('timeout', responseOnTimeout); | ||
while (true) { |
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 suggest avoiding this always-true condition in terms of memory leak issues and looking at enough complexity of the logic below, we probably cannot be sure of triggering the break
in some cases.
Fixes: #39495