Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
6 participants
@addaleax
Copy link
Member

commented Feb 23, 2019

It’s not obvious why this was a heap allocation in the first place,
but it’s unneccessary. Most other HandleWraps also store the
libuv 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), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
@nodejs-github-bot

This comment has been minimized.

Copy link

commented Feb 23, 2019

@addaleax sadly an error occured when I tried to trigger a build :(

@addaleax addaleax added the worker label Feb 23, 2019

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);

This comment has been minimized.

Copy link
@gireeshpunathil

gireeshpunathil Feb 23, 2019

Member

I wanted to ask this earlier as well - what is the consideration behind obtaining this through pointer arithmetic over the other one?

This comment has been minimized.

Copy link
@bnoordhuis

bnoordhuis Feb 23, 2019

Member

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));
}

This comment has been minimized.

Copy link
@gireeshpunathil

gireeshpunathil Feb 23, 2019

Member

how is this change related?

This comment has been minimized.

Copy link
@addaleax

addaleax Feb 23, 2019

Author Member

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.

This comment has been minimized.

Copy link
@gireeshpunathil

gireeshpunathil Feb 24, 2019

Member

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.

@bnoordhuis
Copy link
Member

left a comment

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);

This comment has been minimized.

Copy link
@bnoordhuis

bnoordhuis Feb 23, 2019

Member

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.

@addaleax addaleax force-pushed the addaleax:messageport-async-inline branch from d42e6e2 to be33b22 Feb 23, 2019

addaleax added some commits Feb 23, 2019

worker: make MessagePort `uv_async_t` inline field
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.

@addaleax addaleax force-pushed the addaleax:messageport-async-inline branch from be33b22 to 7c8f4c2 Mar 1, 2019

@addaleax

This comment has been minimized.

Copy link
Member Author

commented Mar 1, 2019

@addaleax

This comment has been minimized.

Copy link
Member Author

commented Mar 1, 2019

Landed in 4dd7c4b, 0fc40c8

@addaleax addaleax closed this Mar 1, 2019

@addaleax addaleax deleted the addaleax:messageport-async-inline branch Mar 1, 2019

addaleax added a commit that referenced this pull request Mar 1, 2019

worker: remove MessagePort::AddToIncomingQueue
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>

addaleax added a commit that referenced this pull request Mar 1, 2019

worker: make MessagePort `uv_async_t` inline field
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>

addaleax added a commit that referenced this pull request Mar 1, 2019

worker: remove MessagePort::AddToIncomingQueue
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>

addaleax added a commit that referenced this pull request Mar 1, 2019

worker: make MessagePort `uv_async_t` inline field
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>

@BridgeAR BridgeAR referenced this pull request Mar 4, 2019

Merged

v11.11.0 proposal #26322

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.