Skip to content

Conversation

@danbev
Copy link
Contributor

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

src

Description of change

One of the issues in #4641 concerns OnConnection in pipe_wrap and
tcp_wrap which are very similar with some minor difference in how
they are coded. This commit extracts OnConnection so both these
classes can share the same implementation.

One of the issues in nodejs#4641 concerns OnConnection in pipe_wrap and tcp_wrap which are very similar with some minor difference in how they are coded. This commit extracts OnConnection so both these classes can share the same implementation.
@nodejs-github-botnodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. build Issues and PRs related to build files or the CI. labels Jul 5, 2016
@mscdexmscdex added net Issues and PRs related to the net subsystem. and removed build Issues and PRs related to build files or the CI. labels Jul 5, 2016
@Fishrock123
Copy link
Contributor

Thanks for the PR! Here is a CI test run: https://ci.nodejs.org/job/node-test-pull-request/3199/

@Fishrock123
Copy link
Contributor

Seems fine to me, tests are passing. i'll let some more C++ -y folks sign-off though.

cc @trevnorris / @addaleax / @bnoordhuis / etc


class ConnectionWrap{
protected:
template<typename WrapType, typename UVType>
Copy link
Member

Choose a reason for hiding this comment

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

It might be nicer to have the templateing done on the class itself, class A : public B<A>{… }; isn’t that uncommon of a pattern + it would allow lifting the handle_ to ConnectionWrap as UVType handle_; (I think?).

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Ah, that does sound better. Let me give that a try and see what you think. Thanks

danbev added 2 commits July 7, 2016 20:21
I originally just wanted to move the handle_ member from tcp_wrap and pipe_wrap without changing its name. But I ran into an issue which I believe is because tcp_wrap and pipe_wrap now extend ConnectionWrap. Both classes are derived from StreamWrap which has an inheritance tree that looks like this: class PipeWrap : public StreamWrap, ConnectionWrap<PipeWrap, uv_pipe_t> class StreamWrap : public HandleWrap, public StreamBase class HandleWrap : public AsyncWrap class AsyncWrap : public BaseObject BaseObject has the following private member: v8::Persistent<v8::Object> handle_; The compiler complains that 'handle_' is found in multiple base classes of different types: ../src/pipe_wrap.cc:130:50: error: member 'handle_' found in multiple base classes of different types reinterpret_cast<uv_stream_t*>(&handle_), ^ ../src/base-object.h:47:30: note: member found by ambiguous name lookup v8::Persistent<v8::Object> handle_; It turns out that name lookup is performed before access rules are considered. C++ standard section 3.4: "The access rules (Clause 11) are considered only once name lookup and function overload resolution (if applicable) have succeeded." It is possible to be explicit about the type you want using the resolution operator ::. So we could use ConnectionWrap::handle_ to tell the compiler which type we want. But going down this route still caused changes to a number of files and I think the code is somewhat clearer using a different name for the handle, and there is no confusion with the handle_ member in BaseObject. Being fairly new to C++ and to the project there this is probably a gap in my knowledge about the best way to solve this. Looking forward to hear about other options/ideas for this.
template<typename WrapType, typename UVType>
UVType* ConnectionWrap<WrapType, UVType>::UVHandle(){
return &uvhandle_;
}
Copy link
Member

Choose a reason for hiding this comment

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

It might be easier to define UVHandle() directly in the header where it’s defined as an inline function?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Sounds, I'll fix that.

@addaleax
Copy link
Member

That handle_ -> uvhandle_ change touches a lot of code… was there anything that made it necessary?

@danbev
Copy link
ContributorAuthor

That handle_ -> uvhandle_ change touches a lot of code… was there anything that made it necessary?

Yeah, it is unfortunate. I've added a comment about this in 34d5abc message.

@addaleax
Copy link
Member

Yeah, it is unfortunate. I've added a comment about this in 34d5abc message.

Sorry, right. Maybe renaming handle_ in BaseObject is easier though, because the changes would be more localized + affect only the name of a private member?

@danbev
Copy link
ContributorAuthor

Maybe renaming handle_ in BaseObject is easier though, because the changes would be more localized + affect only the name of a private member?

That sounds much better. I was not sure if changing BaseObject was "off limits" or not. I'll take a stab at this and your other comments this evening or during the weekend. I appreciate your feedback and help, thanks.

void ConnectionWrap<WrapType, UVType>::OnConnection(uv_stream_t* handle,
int status){
WrapType* wrap_data = static_cast<WrapType*>(handle->data);
CHECK_EQ(&wrap_data->uvhandle_, reinterpret_cast<UVType*>(handle));
Copy link
Contributor

Choose a reason for hiding this comment

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

Mind adding a CHECK_NE(wrap_data, nullptr) just above this?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

No problems, I'll add this.

@trevnorris
Copy link
Contributor

Side note, with this change we can do something about the following in handle_wrap.h:

 // Using double underscore due to handle_ member in tcp_wrap. Probably // tcp_wrap should rename it's member to 'handle'. uv_handle_t* const handle__; 

using v8::Value;


template<typename WrapType, typename UVType>
Copy link
Member

Choose a reason for hiding this comment

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

Tiny style nit: space before <.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I'll correct this.


template uv_pipe_t* ConnectionWrap<PipeWrap, uv_pipe_t>::UVHandle();

template uv_tcp_t* ConnectionWrap<TCPWrap, uv_tcp_t>::UVHandle();
Copy link
Member

Choose a reason for hiding this comment

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

I think these two can be dropped now?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Ah yes, I'll remove them.

@addaleax
Copy link
Member

Landed in 4663393, thank you!

addaleax pushed a commit that referenced this pull request Jul 25, 2016
One of the issues in #4641 concerns OnConnection in pipe_wrap and tcp_wrap which are very similar with some minor difference in how they are coded. This commit extracts OnConnection so both these classes can share the same implementation. PR-URL: #7547 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
@jbergstroem
Copy link
Member

These test failures popped up pretty recently, I fear they might be related. Look at centos5/6 and ubuntu12 bots: https://ci.nodejs.org/job/node-test-commit-linux/4316/

@Trott
Copy link
Member

It looks like 85af1a6 was added after the CI run. So, with no other information, I'd guess that tiny change is the culprit...

Sure enough, undoing that one tiny change fixes it:

https://ci.nodejs.org/job/node-test-commit-linux/4320/

Trott added a commit to Trott/io.js that referenced this pull request Jul 25, 2016
85af1a6 was added (squashed into another commit) without running through CI. Unfortunately, it breaks some of the CI builds, notably on three of the CentOS setups. Undoing that one small change to get builds green again. Refs: nodejs#7547 (comment) PR-URL: nodejs#7873
@Trott
Copy link
Member

Proposed quick-fix: #7873

Trott added a commit to Trott/io.js that referenced this pull request Jul 25, 2016
85af1a6 was added (squashed into another commit) without running through CI. Unfortunately, it breaks some of the CI builds, notably on three of the CentOS setups. Undoing that one small change to get builds green again. Refs: nodejs#7547 (comment) PR-URL: nodejs#7873 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
@evanlucas
Copy link
Contributor

Is this ABI compatible with v6.x? If so, should it be backported?

@addaleax
Copy link
Member

@evanlucas It does not touch any public interfaces afaict, so that shouldn’t be a problem.

@evanlucas
Copy link
Contributor

Thanks @addaleax!

gibfahn pushed a commit to gibfahn/node that referenced this pull request Aug 5, 2016
One of the issues in nodejs#4641 concerns OnConnection in pipe_wrap and tcp_wrap which are very similar with some minor difference in how they are coded. This commit extracts OnConnection so both these classes can share the same implementation. PR-URL: nodejs#7547 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
@cjihrigcjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
One of the issues in #4641 concerns OnConnection in pipe_wrap and tcp_wrap which are very similar with some minor difference in how they are coded. This commit extracts OnConnection so both these classes can share the same implementation. PR-URL: #7547 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Trevor Norris <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]>
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
85af1a6 was added (squashed into another commit) without running through CI. Unfortunately, it breaks some of the CI builds, notably on three of the CentOS setups. Undoing that one small change to get builds green again. Refs: #7547 (comment) PR-URL: #7873 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
@cjihrigcjihrig mentioned this pull request Aug 11, 2016
@danbevdanbev deleted the extracting-onconnection branch September 7, 2016 08:31
Sign up for freeto 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++.lib / srcIssues and PRs related to general changes in the lib or src directory.netIssues and PRs related to the net subsystem.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants

@danbev@Fishrock123@addaleax@trevnorris@bnoordhuis@jbergstroem@Trott@evanlucas@mscdex@nodejs-github-bot