| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Very nice!
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
|
@addaleax I've almost got the resolution for the OS X failure, looking into Windows |
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-pull-request/12088/ |
Sorry, something went wrong.
|
@addaleax This should be ready to review again, just one new commit. The new IsAsync() lets us remove a hack from _writeGeneric which checked whether queue size was 0 alongside req.async (which in turn necessitated a hack in tls.js to make writeQueueSize non-0 during the handshake). Now req.async (WriteWrap.prototype.async) represents the actual async status of a write request. |
Sorry, something went wrong.
There was a problem hiding this comment.
What would happen if you just set this to the actual value of the write queue size at this point? Do you know that?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
Hm … but what if multiple writes were scheduled and this callback ran after the first one finished? That’s a possibility, no?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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…
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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?
Sorry, something went wrong.
There was a problem hiding this comment.
I guess it has a dual purpose. Let me think about it a bit more.
Sorry, something went wrong.
There was a problem hiding this comment.
@apapirovski Maybe make it HasWriteQueue()?
Sorry, something went wrong.
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
Opened an issue on https://github.com/nodejs/build — seems like @mhdawson is looking into it already... I guess we wait. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@addaleax This is ready to review finally, should be the last time. Thanks! |
Sorry, something went wrong.
|
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/ |
Sorry, something went wrong.
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.
|
CI: https://ci.nodejs.org/job/node-test-pull-request-lite/27/ (Rebased after _writableState.length removal landed.) |
Sorry, something went wrong.
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 baking-for-lts as I would like to make sure there are no regressions in user code. It shouldn't need to bake too long though. |
Sorry, something went wrong.
|
This does not land cleanly on v9.x could you please backport |
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
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 at net/tcp-raw* which use writeQueueSize extensively.)
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.
Checklist
Affected core subsystem(s)
net, src, tls, test