-
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
src: make ReqWrap req_ member private #8532
Conversation
Is this |
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 |
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); |
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 you add from_req()
methods that use ContainerOf? You need to make req_
protected.
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'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); |
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.
Ditto.
T req_; | ||
|
||
protected: | ||
T req_; // Must be last. |
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'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?
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.
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.
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.
Ah, that makes sense. Thanks for the explanation!
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.
Yeah, that definitely sounds worth adding to the comment here.
I don’t think we consider anything that’s guarded by |
@addaleax ... good point but I'm wondering if it's safer to be cautious on this, just in case? |
Sure, it probably doesn’t matter anyway. :) |
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.
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.
This could be semver-patch, it only touches internals.
Removing the semver-major label. |
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? |
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
Probably nothing. :)
That should only be the case for |
Ah great, thanks for clarifying. |
Sorry, I deleted my branch by mistake when trying to clean up old PR branches. Reopening and will rebase this. |
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.
b0a7e5d
to
7fa9172
Compare
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>
Landed in 0c64552 |
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected 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.