feat: MConnection prioritizes received messages based on their channel ID priority #1228
Conversation
…m around different routines
staheri14
force-pushed
the
sanaz/asyn-onreaceive
branch
from
03782fa to
6fc3cee
Compare
p2p/conn/connection.go
Outdated
| @@ -869,7 +984,10 @@ func (ch *Channel) recvPacketMsg(packet tmp2p.PacketMsg) ([]byte, error) { | |||
| // suggests this could be a memory leak, but we might as well keep the memory for the channel until it closes, | |||
| // at which point the recving slice stops being used and should be garbage collected | |||
| ch.recving = ch.recving[:0] // make([]byte, 0, ch.desc.RecvBufferCapacity) | |||
| return msgBytes, nil | |||
|
|
|||
| msgCopy := make([]byte, len(msgBytes)) | |||
There was a problem hiding this comment.
[To reviewers] Without creating a new copy, the original output of this function msgBytes and the ch.recving slice would reference the same memory address. Consequently, if msgBytes is passed to another goroutine, it can lead to a race condition [and it does]. Therefore, it's necessary to create a fresh copy to prevent this issue.
staheri14
changed the title
|
The |
staheri14
requested review from
evan-forbes,
cmwaters,
rach-id,
ninabarbakadze and
rootulp
as code owners
|
This PR is ready for review. I am currently waiting for the results from testground to confirm our plan to merge this new logic. Once confirmed, I will mark it as ready for review. In the meantime, please feel free to leave any comments or feedback you may have. |
|
can we close this draft? fixing the receive priority is a good idea, but imo we should instead focus on unblocking each channel/reactor, so something similar to cometbft/cometbft#3230 |
Fine with me, if needed we can reopen it later perhaps. |
Closes #1192