-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
net,src: refactor writeQueueSize tracking #17650
Conversation
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.
Very nice!
Looks like a couple of the CI failures are related, though :(
I can try to look into the Windows failures. Also, I restarted CitGM since one of the build parameters was slightly off |
@addaleax I've almost got the resolution for the OS X failure, looking into Windows |
2a83e33
to
5938061
Compare
@addaleax This should be ready to review again, just one new commit. The new Now |
lib/net.js
Outdated
@@ -870,7 +870,8 @@ function afterWrite(status, handle, req, err) { | |||
if (self !== process.stderr && self !== process.stdout) | |||
debug('afterWrite', status); | |||
|
|||
self[kLastWriteQueueSize] = 0; | |||
if (req.async) | |||
self[kLastWriteQueueSize] = 0; |
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.
What would happen if you just set this to the actual value of the write queue size at this point? Do you know that?
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.
This should always be 0 at this point. I could put an assert to confirm and run our test suite. The getter is obviously a bit more expensive.
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.
Hm … but what if multiple writes were scheduled and this callback ran after the first one finished? That’s a possibility, no?
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.
Only a single write can be scheduled at a time. req.cb()
needs to be called (bottom of this function) before the next one will occur.
src/stream_base.h
Outdated
@@ -162,6 +162,7 @@ class StreamResource { | |||
uv_buf_t* bufs, | |||
size_t count, | |||
uv_stream_t* send_handle) = 0; | |||
virtual bool IsAsync(); |
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.
This feels odd … I think this would be a bit clearer if it was a set/get pair on the WriteWrap
instance, defaulting to true
, where LibuvStreamWrap::DoWrite
sets the value?
I don’t think StreamResource
is the right place for this…
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 think this might be more of a naming issue maybe? I do think it conceptually belongs on StreamResource because it's supposed to represent whether there's anything in the queue. Right now it's mostly for LibuvStreamWrap
but it's not guaranteed that's the only sync write we'll have.
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 mean, yeah, if this stays here I think we could come up with a better name :)
But what we use it for is checking whether a particular write was happening asynchronously, right?
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 guess it has a dual purpose. Let me think about it a bit more.
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.
@apapirovski Maybe make it HasWriteQueue()
?
5938061
to
c81d08a
Compare
@addaleax CI is pointless... :( Windows is down and that's the only system we need. Edit: to clarify, I ran a CI last night for everything else but didn't post it here. Just waiting on Windows & Linux to come back. |
Opened an issue on https://github.com/nodejs/build — seems like @mhdawson is looking into it already... I guess we wait. |
88dc4f1
to
23f0f3f
Compare
0d1c759
to
586dadb
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request/12152/ This should work. Will need to look at some of the write code in the future, there are some differences between Windows & *nix that I'm not necessarily comfortable with. |
@addaleax This is ready to review finally, should be the last time. Thanks! |
I do think we want to run CITGM again, but that should be all: CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1158/ |
Currently, writeQueueSize is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. For the vast majority of cases though, create a new prop on Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this to track the current write size, entirely in JS land.
586dadb
to
a99b447
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request-lite/27/ (Rebased after |
Currently, writeQueueSize is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. For the vast majority of cases though, create a new prop on Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this to track the current write size, entirely in JS land. PR-URL: #17650 Reviewed-By: Anna Henningsen <anna@addaleax.net>
Landed in d36e1b4. I've marked this as |
This does not land cleanly on v9.x could you please backport |
Currently, writeQueueSize is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. For the vast majority of cases though, create a new prop on Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this to track the current write size, entirely in JS land. PR-URL: nodejs#17650
Currently, writeQueueSize is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. For the vast majority of cases though, create a new prop on Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this to track the current write size, entirely in JS land. PR-URL: nodejs/node#17650 Reviewed-By: Anna Henningsen <anna@addaleax.net>
Currently, writeQueueSize is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. For the vast majority of cases though, create a new prop on Socket.prototype[kLastWriteQueueSize] using a Symbol. Use this to track the current write size, entirely in JS land. Backport-PR-URL: #18084 PR-URL: #17650 Reviewed-By: Anna Henningsen <anna@addaleax.net>
Currently,
writeQueueSize
is never used in C++ and barely used within JS. Instead of constantly updating the value on the JS object, create a getter that will retrieve the most up-to-date value from C++. (This has no performance implications based on the benchmarks atnet/tcp-raw*
which usewriteQueueSize
extensively.)For the vast majority of cases though, create a new prop on
Socket.prototype[kLastWriteQueueSize]
using aSymbol
. Use this to track the current write size entirely in JS land.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
net, src, tls, test