GitLab

Or, really, just avoid accessing it. We don't need it.

This caused a concurrent map access panic under load.

Quick alternative to #407 to fix the main issue.

* feat: total wants gauge

* fix: in gauges count wants regardless of which peers they're sent to

* fix: want block gauge calculation

* refactor: simplify peermanagerwants

Instead of tracking offsets, just create a "new" slice starting with the
broadcast cancel slice. Under the covers, this will just use the same memory
over and over.

* fix: use one less go-routine per session

* fix: send cancel when GetBlocks() is cancelled (#383)

* fix: send cancel when GetBlocks() is cancelled

* fix: in SessionManager shutdown nil out sessions

* fix: sessionWantSender perf

* make sessionWantSender.SignalAvailability() non-blocking

* Refactor SessionInterestManager (#384)

* refactor: customize SessionInterestManager

* refactor: SessionInterestManager perf

* feat: small optimizations

* feat: move broadcast wantlist into the peermanager

This deduplicates some state and allows us to do less book-keeping for broadcast
wants. We should probably rename the PeerManager to the WantManager and rename the
WantManager to something else.

* fix: lint warnings

* refactor: add reverse index to peerWantManager to speed up cancels

* refactor: in peerWantManager use ForEach instead of allocating lists

* fix: minimize time holding wantlist lock

Instead of holding the lock the entire time we prepare a message, hold the lock
while we retrieve the wantlist entries, process the entries without the lock,
retake the lock, then mark entries as sent.

This means:

1. We never sort entries while holding the lock.
2. We allocate exactly three times while holding the lock (once per entry list).

* fix: address code review

Instead of copying these slices, we can just reuse them.