We send a newly-accepted peer a 1000-entry addr message, and then only use
vAddrToSend for small messages. Deallocate vAddrToSend after it's been used for
the big message to save about 40 kB per connected inbound peer.
Optimistically test the latch bool before taking the lock.
For all IsInitialBlockDownload calls after the first to return false,
this avoids the need to lock cs_main.
An orphan whos parents were rejected is never going to connect, so there
is little utility in keeping it.
Orphans also helpfully tell us what we're missing, so go ahead and treat
it as INVed.
This prevents higher order orphans and other junk from
holding positions in the orphan map. Parents delayed
twenty minutes are more are unlikely to ever arrive.
The freed space will improve the orphan matching success rate for
other transactions.
This reverts commit caf6150e97.
getaddrinfo_a has a nasty tendency to segfault internally in its
background thread, on every version of glibc I tested, especially
under helgrind.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20874
Github-Pull: #9229
Rebased-From: 10ae7a7b2316f8052ec58ef237ce6dd987300900
swap was using an incorrect condition to determine when to apply an optimization
(not swapping the full direct[] when swapping two indirect prevectors).
Rather than correct the optimization I'm removing it for simplicity. Removing
this optimization minutely improves performance in the typical (currently only)
usage of member swap(), which is swapping with a freshly value-initialized
object.
Fixes a bug in which pop_back did not call the deleted item's destructor.
Using the most general erase() implementation to implement all the others
prevents similar bugs because the coupling between deallocation and destructor
invocation only needs to be maintained in one place.
Also reduces duplication of complex memmove logic.
Make a copy of the boost time-point to wait for, otherwise the head of
the queue may be deleted by another thread while this one is waiting,
while the boost function still has a reference to it.
Although this problem is in non-test code, this is not an actual problem
outside of the tests because we use the thread scheduler with only one
service thread, so there will never be threads fighting at the head of
the queue.
The old boost fallback escapes this problem because it passes a scalar
value to wait_until instead of a const object reference.
Found by running the tests in LLVM-4.0-master asan.
Github-Pull: #9186
Rebased-From: 12519bf62b8c49b1c1744eca6ea5b3162a61f962
