GitLab

Goprocess returns a _custom_ context type. Unfortunately, golang has a bunch of
magic type assertions to efficiently handle built-in context types but launches
a new goroutine when deriving a new context from a custom context type.
Otherwise, it has no way to wait on the custom context's channel.

This fix just ensures we only ever have one of goroutines per provide worker by
deriving a (normal) cancelable context up-front and then using that.

fix(prq): fix a bunch of goroutine leaks and deadlocks

Otherwise, we'll wait forever.

remove allocations round two

gx publish 1.1.28

fix(bitswap): remove CancelWants function

Avoid allocating for wantlist entries

ci(Jenkins): remove Jenkinsfile

Jenkins is EOL as the CI so remove Jenkinsfile to disable it

Fixes #50.

Each one is about 4 words wide (two for the CID, one for the priority, one for
the trash flag).

We allocate a _lot_ of these.

More specific wantlists

put trash field only where it is needed, in peer request queues

Seperate want list into differentiated types - session tracking and regular

fix #13

fix(wantlist): remove races on setup

Move refcnt tracking from the messagequeue to the peermanager, where it's relevant

fix remaining issues for race detector in peer manager

Keep all of disconnection in a mutex

repace get/set with getOrCreate to keep operations atomic

Constrain use of mutex to actual operations on the peerQueues map via utility functions

Breakup Startup function so that wantlists are not sent with each call to SendMessage

If wantlist changes are present, send them immediately on startup, rather than as a seperate message

Limit retrying sending of a message even when a successful reconnect occurs

fix race conditions while setting up wantlists by creating peer queues on demand

BREAKING CHANGE: PeerManager SendMessage signature changed

fix #51

fix multiple data races

Ensures that we don't leave goroutines behind, even if the client forgets to
unsubscribe.