-
Notifications
You must be signed in to change notification settings - Fork 30k
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 uv_async_t
inline field
#26271
Conversation
@addaleax sadly an error occured when I tried to trigger a build :( |
AsyncWrap::PROVIDER_MESSAGEPORT), | ||
data_(new MessagePortData(this)) { | ||
auto onmessage = [](uv_async_t* handle) { | ||
// Called when data has been put into the queue. | ||
MessagePort* channel = static_cast<MessagePort*>(handle->data); | ||
MessagePort* channel = ContainerOf(&MessagePort::async_, handle); |
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 wanted to ask this earlier as well - what is the consideration behind obtaining this
through pointer arithmetic over the other one?
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.
For one, the address can't change; the contents of handle->data
can.
In fact, the old code is mildly wrong because HandleWrap also sets handle_->data = this
(where this
is an instance of HandleWrap rather than MessagePort) so static_casting that to MessagePort afterwards would be wrong if multiple inheritance were involved.
@@ -472,21 +472,13 @@ MessagePort::MessagePort(Environment* env, | |||
Debug(this, "Created message port"); | |||
} | |||
|
|||
void MessagePort::AddToIncomingQueue(Message&& message) { | |||
data_->AddToIncomingQueue(std::move(message)); | |||
} |
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.
how is this change related?
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.
It’s not, it’s just something that I noticed, and putting it into another PR would have lead to yet another merge conflict. I’ve split it into a separate commit, as @bnoordhuis suggested.
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.
thanks. part of my question (which I meant to ask but did not come out like that) was why this change required at all - that is not covered in the PR description. But I got it now as: it is an unused piece of code.
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.
The removal of MessagePort::AddToIncomingQueue()
should arguably be a separate commit.
AsyncWrap::PROVIDER_MESSAGEPORT), | ||
data_(new MessagePortData(this)) { | ||
auto onmessage = [](uv_async_t* handle) { | ||
// Called when data has been put into the queue. | ||
MessagePort* channel = static_cast<MessagePort*>(handle->data); | ||
MessagePort* channel = ContainerOf(&MessagePort::async_, handle); |
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.
For one, the address can't change; the contents of handle->data
can.
In fact, the old code is mildly wrong because HandleWrap also sets handle_->data = this
(where this
is an instance of HandleWrap rather than MessagePort) so static_casting that to MessagePort afterwards would be wrong if multiple inheritance were involved.
d42e6e2
to
be33b22
Compare
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly.
be33b22
to
7c8f4c2
Compare
Rebased, new CI: https://ci.nodejs.org/job/node-test-pull-request/21081/ |
PR-URL: #26271 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly. PR-URL: #26271 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
PR-URL: #26271 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly. PR-URL: #26271 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
It’s not obvious why this was a heap allocation in the first place,
but it’s unneccessary. Most other
HandleWrap
s also store thelibuv handle directly.
(This is going to have a minor merge conflict with #26099 so I’d wait until after that one lands before merging this.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes