mirror of
https://github.com/status-im/status-go.git
synced 2025-01-21 20:20:29 +00:00
24a30d7a7c
This is a bit complicated, so: 1) Peerpool was subscribing to `event.Feed`, which is a global event emitter for ethereum. 2) The p2p.Server was publshing on `event.Feed`, this triggered in the same routine a publish on `event.Feed`. 3) Peerpool was listening to `event.Feed`, react on it, and in the same routine, trigger some code on p2p.Server that would publish on `event.Feed` This meant that if the size of the channel was unbufferred, it would deadlock, as peerPool would not be consuming when it would publish (the same go routine publishes and listen effectively, through a lot of indirection and non-buffered channels, p2p.Server->event.Feed) The channel though was a buffered channel with size 10, and this meant that most of the times is fine. The issue is that peerpool is not the only producer to this channel. So it's possible that while is processing an event, the buffer would fill up, and it would hange trying to publish, and nobody is listening to the channel, hanging EVERYTHING. At least that's what I think, needs to be tested, but definitely an issue. I kept the code changes to a minimum, this code is a bit hairy, but it's fairly critical so I don't want to make too many changes.
Status bindings for go-ethereum
Docs
- How to Build
- How to Contribute
- How to Release
- How to run a Bootnode
- How to run a Mailserver
- How to run a Waku node
- How to configure status-go