worker: prevent event loop starvation through MessagePorts #29315
Conversation
nodejs-github-bot
added
the
c++
addaleax
force-pushed
the
message-port-event-loop-starvation-2
branch
from
d69503b
to
6db2d79
Compare
addaleax
added
author ready
|
Actually, it looks like this also makes some trouble on Windows. |
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.
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
addaleax
force-pushed
the
message-port-event-loop-starvation-2
branch
from
6db2d79
to
fab5d00
Compare
|
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.) |
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. |
addaleax
added
the
author ready
|
Landed in b34f05e |
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>
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>
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 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