Skip to content
This repository has been archived by the owner on Feb 1, 2023. It is now read-only.

fix(messagequeue): Remove second run loop #94

Merged
merged 1 commit into from
Mar 4, 2019

Conversation

hannahhoward
Copy link
Contributor

Goals

Ideally, fix #92

Implementation

Revert to the old go-routine architecture for the messagequeue.

I originally setup the second go-routine because I believed I needed to block access to the wantlist inside a go-routine, which no longer has a mutex. however, I now see that the lock that was previously used for building the outgoing message actually covers all cases where the wantlist is modified. At minimum, it can't hurt to revert to previous setup and remove the loop that is causing so many problems. It is difficult to tell if the problem however is related to the loop itself or just sending more messages.

This does pass go test --race FWIW.

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

fix #92
@ghost ghost assigned hannahhoward Mar 4, 2019
@ghost ghost added the status/in-progress In progress label Mar 4, 2019
@Stebalien Stebalien merged commit 7fd8d7c into master Mar 4, 2019
@ghost ghost removed the status/in-progress In progress label Mar 4, 2019
@Stebalien
Copy link
Member

This can only help, even if it doesn't fully fix the issue.

@Stebalien Stebalien deleted the bugs/runqueue-performance branch March 4, 2019 22:11
Jorropo pushed a commit to Jorropo/go-libipfs that referenced this pull request Jan 26, 2023
…ance

fix(messagequeue): Remove second run loop

This commit was moved from ipfs/go-bitswap@7fd8d7c
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

High CPU usage when sending messages
2 participants