GitLab

fix: limit use of custom context type

fix: remove non-error log message

fix(messagequeue): Remove second run loop

Revert to the old go-routine architecture for the messagequeue, which I believe is still compatible
w/ wantlist w/o mutex

fix #92

This can happen even when everything is working correctly.

fixes https://github.com/ipfs/go-ipfs/issues/6046

add gomod support // tag v0.0.1.

License: MIT
Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>

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