-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
worker_threads: inconsistent stop/start behavior with MessagePort.onmessage #26463
Labels
worker
Issues and PRs related to Worker support.
Comments
chjj
added a commit
to chjj/bthreads
that referenced
this issue
Mar 6, 2019
chjj
added a commit
to chjj/bthreads
that referenced
this issue
Mar 6, 2019
4 tasks
addaleax
added a commit
to addaleax/node
that referenced
this issue
Mar 10, 2019
This aligns `MessagePort`s more with the web API. Refs: nodejs#26463
juanarbol
added a commit
to juanarbol/node
that referenced
this issue
May 3, 2021
This reverts commit 73370b4. The unit test is preserved to make sure it does not break nodejs#26463 again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
These two samples of code differ in output between node.js and the browser:
Browser (Chromium 72.0.3626.119):
Output:
node.js with identical logic:
Output:
The reason for this is that node.js calls
stopMessagePort()
[1] [2] [3] when theonmessage
listener is removed (likewise for.on('message')
). This causes the port to start buffering messages again and is the reason why we can still getworld
once we rebind the event listener. The browser does not implement this behavior: once a MessagePort is started, it is started forever until closed.(Another small thing to consider:
port.onmessage = () => {}
starts the port in the browser whereasport.addEventListener('message', () => {})
does not.)The second strange thing that I've found, which is sort of related to the
stopMessagePort()
behavior involves closing MessagePorts.Here is an example:
Throws:
There seems to be a small window of time where removing the message listener will throw after the port is closed (putting the
port1.off(...)
call in asetTimeout
doesn't seem to produce the error) [4] [5]. The browser never throws when removing events (partially because it doesn't implement this auto-stop behavior).The text was updated successfully, but these errors were encountered: