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

src: make ReqWrap req_ member private #8532

Closed
wants to merge 3 commits into from

Conversation

danbev
Copy link
Contributor

@danbev danbev commented Sep 14, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

src

Description of change

This commit attempts to address one of the items in
#4641 which is
related to src/req-wrap.h and making the req_ member private.

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Sep 14, 2016
@danbev
Copy link
Contributor Author

danbev commented Sep 14, 2016

@Fishrock123
Copy link
Contributor

Is this semver-major?

@Trott
Copy link
Member

Trott commented Sep 14, 2016

@bnoordhuis

@danbev
Copy link
Contributor Author

danbev commented Sep 15, 2016

Is this semver-major?

Good point, it is changing a public field and might break something so I think that qualifies. I'll label it as semver-major. Thanks

@danbev danbev added the semver-major PRs that contain breaking changes and should be released in the next major version. label Sep 15, 2016
req_wrap->Dispatched();
return err;
}


void StreamWrap::AfterShutdown(uv_shutdown_t* req, int status) {
ShutdownWrap* req_wrap = ContainerOf(&ShutdownWrap::req_, req);
ShutdownWrap* req_wrap = static_cast<ShutdownWrap*>(req->data);
CHECK_NE(req_wrap, nullptr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add from_req() methods that use ContainerOf? You need to make req_ protected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a commit with from_req() methods. Let me know if this was what you had in mind. Thanks

@@ -360,7 +361,8 @@ int StreamWrap::DoWrite(WriteWrap* w,


void StreamWrap::AfterWrite(uv_write_t* req, int status) {
WriteWrap* req_wrap = ContainerOf(&WriteWrap::req_, req);
WriteWrap* req_wrap = static_cast<WriteWrap*>(req->data);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

T req_;

protected:
T req_; // Must be last.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to add some more information about the reason for this requirement, that it be the last member. Moving the protected member to be before the private members will cause failures in tests, but I've not been able to find the reason for this yet. @bnoordhuis Are there any resources (links, docs) you could point me to, to help me understand this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

req_wrap_queue_ needs to be at a fixed offset from the start of the struct because it is used by ContainerOf to calculate the address of the embedding ReqWrap.

ContainerOf compiles down to simple, fixed pointer arithmetic. sizeof(req_) depends on the type of T so req_wrap_queue_ would no longer be at a fixed offset if it came after req_.

It's a bit of a hack in that it depends on the layout in memory but I deemed it less worse than the untyped queue that we used before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes sense. Thanks for the explanation!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that definitely sounds worth adding to the comment here.

@addaleax
Copy link
Member

Is this semver-major?

Good point, it is changing a public field and might break something so I think that qualifies. I'll label it as semver-major. Thanks

I don’t think we consider anything that’s guarded by NODE_WANT_INTERNALS part of the public API?

@jasnell
Copy link
Member

jasnell commented Sep 20, 2016

@addaleax ... good point but I'm wondering if it's safer to be cautious on this, just in case?

@addaleax
Copy link
Member

Sure, it probably doesn’t matter anyway. :)

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be semver-patch, it only touches internals.

@jasnell jasnell removed the semver-major PRs that contain breaking changes and should be released in the next major version. label Sep 21, 2016
@jasnell
Copy link
Member

jasnell commented Sep 21, 2016

Removing the semver-major label.

@danbev
Copy link
Contributor Author

danbev commented Sep 22, 2016

Thanks for all the reviews on this!

This is the first time I've submitted a PR that might affect a semver change, possibly a semver-patch as noted above, and I'm not sure what I need to do. I looked through the onboarding guide again but could only find information about adding a label to the issue tracker, and that more than one LGTM is required for a semver PR. Could someone advice me on any action I need to take?

@addaleax
Copy link
Member

This is the first time I've submitted a PR that might affect a semver change, possibly a semver-patch as noted above

It’s a bit weird applying semver principles to changes that are not supposed to effect change of the visible behaviour, but we usually consider all commits that are not semver-major or semver-minor to be implicitly semver-patch. (That’s why there is no label for patches.)

and I'm not sure what I need to do.

Probably nothing. :)

and that more than one LGTM is required for a semver PR.

That should only be the case for semver-major changes, but even so, this PR already has two LGTMs from CTC members.

@danbev
Copy link
Contributor Author

danbev commented Sep 23, 2016

Probably nothing. :)

Ah great, thanks for clarifying.

@danbev danbev closed this Sep 23, 2016
@danbev danbev deleted the make_req_private branch September 23, 2016 05:45
@danbev danbev restored the make_req_private branch September 23, 2016 05:49
@danbev
Copy link
Contributor Author

danbev commented Sep 23, 2016

Sorry, I deleted my branch by mistake when trying to clean up old PR branches. Reopening and will rebase this.

@danbev danbev reopened this Sep 23, 2016
This commit attempts to address one of the items in
nodejs#4641 which is
related to src/req-wrap.h and making the req_ member private.
bnoordhuis provided details about the requirement of req_ having come
after req_wrap_queue_, and I'm simply adding them as a comment to the
req_ field.
@danbev
Copy link
Contributor Author

danbev commented Sep 23, 2016

danbev added a commit to danbev/node that referenced this pull request Sep 23, 2016
This commit attempts to address one of the items in
nodejs#4641 which is
related to src/req-wrap.h and making the req_ member private.

PR-URL: nodejs#8532
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@danbev
Copy link
Contributor Author

danbev commented Sep 23, 2016

Landed in 0c64552

@danbev danbev closed this Sep 23, 2016
@danbev danbev deleted the make_req_private branch September 26, 2016 04:00
jasnell pushed a commit that referenced this pull request Sep 29, 2016
This commit attempts to address one of the items in
#4641 which is
related to src/req-wrap.h and making the req_ member private.

PR-URL: #8532
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Fishrock123 pushed a commit that referenced this pull request Oct 11, 2016
This commit attempts to address one of the items in
#4641 which is
related to src/req-wrap.h and making the req_ member private.

PR-URL: #8532
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants