Uh oh!
There was an error while loading. Please reload this page.
worker: prevent event loop starvation through MessagePorts - #29315
Closed
addaleax wants to merge 2 commits into
Closed
worker: prevent event loop starvation through MessagePorts#29315addaleax wants to merge 2 commits into
addaleax wants to merge 2 commits into
Conversation
addaleaxforce-pushed
the
message-port-event-loop-starvation-2
branch
from
August 25, 2019 16:48
d69503b to
6db2d79Comparenodejs-github-bot
commented
Aug 25, 2019
Collaborator
devsnek
approved these changes
Aug 25, 2019
cjihrig
approved these changes
Aug 25, 2019
addaleax
commented
Aug 25, 2019
MemberAuthor
Actually, it looks like this also makes some trouble on Windows. |
jasnell
approved these changes
Aug 26, 2019
Fishrock123
approved these changes
Aug 27, 2019
Trott
previously requested changes
Aug 29, 2019
Trott
left a comment
Member
There was a problem hiding this comment.
Marking with "request changes" so no one accidentally lands this before the Windows tests are passing. Feel free to dismiss this request-for-changes once the tests are passing.
13 tasks
nodejs-github-bot
commented
Sep 7, 2019
Collaborator
Limit the number of messages processed without interruption on a given `MessagePort` to prevent event loop starvation, but still make sure that all messages are emitted that were already in the queue when emitting began. This aligns the behaviour better with the web. Refs: nodejs#28030
addaleaxforce-pushed
the
message-port-event-loop-starvation-2
branch
from
September 7, 2019 19:41
6db2d79 to
fab5d00Compareaddaleax
commented
Sep 7, 2019
MemberAuthor
Turns out the timeouts on Windows were happening because the way this change modified behaviour actually impacted performance on Windows noticeably – in CI, that is. I couldn’t reproduce any issues locally. I’ve rebased this PR and modified it so that at least 1k messages are processed in one batch, which still meets the requirements of not starving the event loop and makes our Windows CI happy. (I’ll kick off CI but linuxone is down currently so it won’t pass at least because of that.) |
nodejs-github-bot
commented
Sep 7, 2019
Collaborator
Trott
commented
Sep 7, 2019
Member
Not sure who is aware and who isn't, so posting this: According to nodejs/build#1909 (comment), the LinuxONE maintenance outage should be over in less than 5 hours. I imagine if you leave the CI running, it will eventually kick off and (hopefully) pass. |
nodejs-github-bot
commented
Sep 9, 2019
Collaborator
nodejs-github-bot
commented
Sep 9, 2019
Collaborator
addaleax
commented
Sep 9, 2019
MemberAuthor
Landed in b34f05e |
addaleax added a commit
that referenced
this pull request
Sep 9, 2019
Limit the number of messages processed without interruption on a given `MessagePort` to prevent event loop starvation, but still make sure that all messages are emitted that were already in the queue when emitting began. This aligns the behaviour better with the web. Refs: #28030 PR-URL: #29315 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
targos pushed a commit
that referenced
this pull request
Sep 20, 2019
Limit the number of messages processed without interruption on a given `MessagePort` to prevent event loop starvation, but still make sure that all messages are emitted that were already in the queue when emitting began. This aligns the behaviour better with the web. Refs: #28030 PR-URL: #29315 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Merged
BridgeAR pushed a commit
that referenced
this pull request
Sep 25, 2019
Limit the number of messages processed without interruption on a given `MessagePort` to prevent event loop starvation, but still make sure that all messages are emitted that were already in the queue when emitting began. This aligns the behaviour better with the web. Refs: #28030 PR-URL: #29315 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
This was referenced Sep 25, 2019
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a re-do of #28030 that also respects another web platform test (that messages that are queued before a .close() call are also emitted).
Limit the number of messages processed without interruption on a
given
MessagePortto prevent event loop starvation, but stillmake sure that all messages are emitted that were already in the
queue when emitting began.
This aligns the behaviour better with the web.
Refs: #28030
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes