I'd love to be making more connect attempts to distinct hosts at once, but I'm not super eager to add more threads: each one implies quite a few megabytes of additional memory usage (both res and virt, from the per thread stacks and the malloc pools) which are problematic on low memory systems. Perhaps it's ultimately worth it, but have you looked into just making the connects() non-blocking and handling them asynchronously?

Startup isn't the only time this should be useful, it would also be nice to reconnect quickly when we've lost our peers due to a network interruption.

Aside, I don't see what in this is preventing it from trying the same netgroup multiple times concurrently, which should probably be avoided. (Perhaps by just passing in a filter to addrman to tell it to return only hosts where netgroup%threads==thread ?)

Aside, I don't see what in this is preventing it from trying the same netgroup multiple times concurrently, which should probably be avoided. (Perhaps by just passing in a filter to addrman to tell it to return only hosts where netgroup%threads==thread ?)

It's putting the addresses being tried in vFastConnect which contains a bool/address pair. The bool is true if the address is ready to be tried, and false if it's finished with and ready to be replaced. If the bool is true, the address's group is added to setConnected when picking new addresses to try, which should prevent the same netgroup from being tried multiple times.

(I was trying for something not too intrusive, so haven't looked at async/non-blocking connect())

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• net: improve code documentation for dns seed behaviour #19084 (net: add comments on dns seed behaviour by ajtowns)
• refactor: Cleanup thread ctor calls #19064 (refactor: Cleanup thread ctor calls by hebasto)
• net: Fix CThreadInterrupt::sleep_for TSan issues #19029 (net: Fix CThreadInterrupt::sleep_for TSan issues by hebasto)
• Add extra thread for scheduler, move TorControl and OpenAddedConnections to scheduler #18925 (Add extra thread for scheduler, move TorControl and OpenAddedConnections to scheduler by naumenkogs)
• p2p: Delay querying DNS seeds #16939 (p2p: Delay querying DNS seeds by ajtowns)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@naumenkogs Did you want to have a look here and Concept ACK or NACK ?

I think the trade-off is straightforward, as Greg points out: bootstrap speed vs. memory usage.

It certainly would be more attractive if we make non-blocking connections instead, but I don't have an idea of how much effort that would require.

If we decide to stick to the current proposal, perhaps we can pass this as an argument?
Just --fast-bootstrap for now, and then we might merge it with something else (for example, with the default memory allocation for utreexo cache or whatnot) so that at the end we have high-memory mode? Let me know if this discussion happened before and there is a consensus that parameters like this is generally a bad idea :)

I think #16939 is enough to stop the privacy leak here, but would still be nice to connect to nodes more quickly. I think it might not be too hard to do a select() loop just for non-proxied (and non-tor) connections, so I'll give that a go.

Dropping this for now