-
Notifications
You must be signed in to change notification settings - Fork 28.8k
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: align MessagePort message handling more with Web #26487
Conversation
365a595
to
8354833
Compare
/cc @nodejs/workers |
doc/api/worker_threads.md
Outdated
@@ -203,6 +203,11 @@ input of [`port.postMessage()`][]. | |||
Listeners on this event will receive a clone of the `value` parameter as passed | |||
to `postMessage()` and no further arguments. | |||
|
|||
When there are `'message'` event listeners and `.start()` is not called | |||
explicitly, and the Web-based `.onmessage` property is not used, no messages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we capitalize web
generally so maybe web-based
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Maybe web-baed
should be removed? It seems likely to be misunderstood. I think we just mean "modeled on the analogous web-based API" but people are likely to interpret as more like...something to do with the web directly? That's what I did when I read this for a few seconds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Both comments above are non-blocking.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think removing web-based
would be a bit confusing, given that we don’t currently document onmessage
ourselves.
I'd like to look at this more closely. To keep things clear, the current behavior on master is:
This PR changes the behavior to:
I believe the browser behavior should be:
I'll have to write up some code to confirm that the latter is actually the browser behavior (I haven't actually confirmed that If that is the behavior, I think there's one more thing to consider: the browser doesn't have references since it's an ever-living event loop (I'm pretty sure workers can't exit gracefully in-browser). That said, we could maybe consider removing the magical referencing behavior of It's probably worth discussing a bit more before anything is merged. |
@chjj I think you’re correct about the behaviour everywhere here. The behaviour for the Node.js-style APIs was picked because it made the most sense to me, and since the browser has neither For example, the “event” that the |
@addaleax, yeah, the more I think about it, the way node does it makes more sense than the browser. In my own worker compatibility module, I actually hack the browser into behaving like node since it seemed to make more sense in the end. Personally, I'd be fine with having things stay the way they are and simply document the difference (i.e. node.js will automatically start and stop the buffering of the port). Anyway, I'm going to tinker with the browser more to confirm the exact behavior. Right now, I suspect that |
I've confirmed that MDN was correct about I've also confirmed that DedicatedWorkerGlobalScope behaves like a
edit: I take it all back. I've spent the last hour trying to hash out a sane model which matches the browser. I slowly started diverging from the browser each time something didn't feel quite right until I arrived at node.js's current behavior. Node is right, the browser is wrong. |
@chjj So… where would you stand on this PR itself? I agree with you in that the browser behaviour is odd, but I also see value in explicitly aligning with the Web spec here. Then again, I’m not even sure that the difference is guaranteed to be observable, because in theory receiving a message can take an arbitrary amount of time (and thus just “randomly” happen when a new I’m personally happy to close this and just document the difference, as you suggested above? |
@addaleax, as far as the PR, I'd say the |
This aligns `MessagePort`s more with the web API. Refs: nodejs#26463
ab4fae7
to
77f6b8c
Compare
@chjj Okay, I think we’re in agreement – I’ve removed the changes for @gireeshpunathil @benjamingr Do you want to take another look? |
still LGTM. |
CI https://ci.nodejs.org/job/node-test-pull-request/21404/ (:heavy_check_mark:) |
This aligns
MessagePort
s more with the web API and resolved #26463.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes