Skip to content

Conversation

4tar
Copy link
Contributor

@4tar 4tar commented May 30, 2014

This is the re-submit of PR 4215, just combine all several commits in that PR into one. The previous discussion could be checked here: #4215.

In the LookupIntern(), things changed are:

  1. Call getaddrinfo_a() instead of getaddrinfo() if available, the former is a sync version of the latter;
  2. Try using inet_pton()/inet_addr() to convert the input text to a network addr structure at first, if success the extra name resolving thread inside getaddrinfo_a() could be avoided;
  3. An interruption point added in the waiting loop for return from getaddrinfo_a(), which completes the improve for thread responsiveness.

A easy way to see the effect is to kick off a 'bitcoind stop' immediately after 'bitcoind -daemon', before the change it would take several, or even tens of, minutes on a bad network situation to wait for the running bitcoind to exit, now it costs only seconds.

Signed-off-by: Huang Le 4tarhl@gmail.com

In the LookupIntern(), things changed are:
  1. Call getaddrinfo_a() instead of getaddrinfo() if available, the former is a sync version of the latter;
  2. Try using inet_pton()/inet_addr() to convert the input text to a network addr structure at first, if success the extra name resolving thread inside the async getaddrinfo_a() could be avoided;
  3. An inturrption point added in the waiting loop for return from getaddrinfo_a(), which completes the improve for thread responsiveness.

Signed-off-by: Huang Le <4tarhl@gmail.com>
@@ -71,9 +83,30 @@ bool static LookupIntern(const char *pszName, std::vector<CNetAddr>& vIP, unsign
}
}

#ifdef HAVE_GETADDRINFO_A
Copy link
Member

Choose a reason for hiding this comment

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

Does this section rely on getaddrinfo_a?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sipa No, it doesn't. But It would be unnecessary if getaddrinfo_a() is unavailable, since placing a call to inet_pton()/inet_addr() first is to avoid the extra thread inside getaddrinfo_a(), else getaddrinfo() can take care of everything.

@jgarzik
Copy link
Contributor

jgarzik commented Jun 4, 2014

Seems straightforward enough, but simplistic. getaddrinfo_a() allows for async callbacks, eliminating the need for any wait loop.

@laanwj
Copy link
Member

laanwj commented Jun 4, 2014

@jgarzik But the point here is only to make the DNS lookup interruptible, I think getting a hand-rolled callback-based system to cooperate with boost threads will be complicated.
Might as well switch to boost::asio which implements all this already, and in a cross-platform way.

@4tar
Copy link
Contributor Author

4tar commented Jun 5, 2014

@laanwj Yes using Asio sounds a better way, let me test it locally and report back.

@laanwj
Copy link
Member

laanwj commented Jun 5, 2014

@4tar Though you may run into other, new problems there, as the rest of the net/netbase code doesn't use boost::asio, and you have to convert addresses, BoostAsioToCNetAddr which I introduced with the subnet matching may come in handy here, see ee21912 and 21bf3d2.

@gmaxwell
Copy link
Contributor

gmaxwell commented Jun 5, 2014

Boost ASIO is pretty awful in my experience, it's buggy, non-performant (it spends a bunch of time thrashing the allocator), results in random deadlocks in even moderately complex code, and its virtually impossible to debug.

I'm not clear on what needs to change here wrt DNS resolution— we've already move the dnsseeds into a thread. If we're doing anything performance critical depending on DNS that in and of itself might be the mistake. :)

@laanwj
Copy link
Member

laanwj commented Jun 5, 2014

@gmaxwell This is not about performance, it doesn't matter at this particular point. The pull just aims to make shutdown more reliable. getaddrinfo is not interruptible, which means that shutdown of bitcoind will wait which may take a long time.

If boost::asio is so awful (which I sort-of agree on, at least the debugging aspect), any points for a better network library we could switch to for at least RPC? I'm sure this is something that has been done and re-done over the ages and it serves us no purpose to try to reinvent everything.

@4tar
Copy link
Contributor Author

4tar commented Jun 6, 2014

@laanwj Wow, didn't notice your previous comment and had done it again... Yes, this method is pretty handy for this purpose, I'd like suggest to put it as another CNetAddr constructor instead of a independent function. Actually I've implement it so, will submit a PR including this change soon, and I have to say that boost::asio was discovered to be not perfect for this case...

@BitcoinPullTester
Copy link

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/p4259_b28a3bee9f8250e083b715a98df7dd7208db0f37/ for test log.

This pull does not merge cleanly onto current master
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

@4tar 4tar closed this Jun 26, 2014
@4tar 4tar deleted the async_resolve branch June 26, 2014 18:52
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants