worker: prevent event loop starvation through MessagePorts #28030
Conversation
Limit the number of messages processed without interruption on a given `MessagePort` to prevent event loop starvation. This aligns the behaviour better with the web.
addaleax
added
c++
|
|
@addaleax cool, do you have an order to go through the tests? We talked about auditing the WPT and port as much as possible before moving workers out of experimental, so some kind of checklist might be helpful to track the progress. (I can probably script some checklist using node-core-utils, if you like) |
| } | ||
|
|
||
| port2.postMessage(0); | ||
| assert(count++ < 10000, `hit ${count} loop iterations`); |
There was a problem hiding this comment.
It may be useful to document that this depends on the constant in the source - in case someone wants to turn it down later. Or we could also export the constant and do some math here..
(Non-blocking BTW)
I’ve gone through all the files in the order in which my editor opened them, and opened PRs along the way 🙂 There’s one left, and it may require a (slightly?) different approach here, because the current queue of messages should still end up being processed even if one of the message handlers closes the port; and this PR would break that, because after closing the port, |
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
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
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>
Limit the number of messages processed without interruption on a
given
MessagePortto prevent event loop starvation.This aligns the behaviour better with the web.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes