-
Notifications
You must be signed in to change notification settings - Fork 29.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: make MessagePort constructor non-callable #28032
Conversation
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.
LGTM if CI is green. I guess since worker_threads
are still Experimental, this can technically still land as a patch in 12.x even if it is deemed semver-major
. (But I'm OK if we'd rather be cautious. Fine either way.)
GetMessagePortConstructor(env, context).ToLocalChecked()) | ||
.Check(); | ||
GetMessagePortConstructorTemplate(env) | ||
->GetFunction(context).ToLocalChecked()).Check(); |
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.
Can't we just use ConstructorBehavior::kThrow
for this? If there is a particular reason for throwing our own style of errors I think that's worth a comment..
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.
@joyeecheung Yeah, it doesn’t work because that also removes the prototype
property. I’m adding a comment, though.
09d50f0
to
9902484
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Refactor the C++ code for creating `MessagePort`s to skip calling the constructor and instead directly instantiating the `InstanceTemplate`, and always throw an error from the `MessagePort` constructor. This aligns behaviour with the web, and creating single `MessagePort`s does not make sense anyway.
9902484
to
a28b289
Compare
This comment has been minimized.
This comment has been minimized.
Landed in 0640526 |
Refactor the C++ code for creating `MessagePort`s to skip calling the constructor and instead directly instantiating the `InstanceTemplate`, and always throw an error from the `MessagePort` constructor. This aligns behaviour with the web, and creating single `MessagePort`s does not make sense anyway. PR-URL: nodejs#28032 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Refactor the C++ code for creating `MessagePort`s to skip calling the constructor and instead directly instantiating the `InstanceTemplate`, and always throw an error from the `MessagePort` constructor. This aligns behaviour with the web, and creating single `MessagePort`s does not make sense anyway. PR-URL: #28032 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Refactor the C++ code for creating
MessagePort
s to skip calling theconstructor and instead directly instantiating the
InstanceTemplate
,and always throw an error from the
MessagePort
constructor.This aligns behaviour with the web, and creating single
MessagePort
sdoes not make sense anyway.
This is technically a breaking change and I’d be happy to split out the added throw into a separate PR out of caution, if anybody considers that a good idea.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes