Closed theoreticalbts closed 3 years ago
Crash should be fixed by #6.
This ticket now represents refactoring to use channels / communicating sequential process instead of a mutex.
That #6 has been merged raises some questions about this refactoring:
Therefore given #6 has been merged, AFAICT the refactoring suggested in this ticket is now simply a matter of style.
With a long-running connection, Golang exited with
fatal error: concurrent map writes
. The problem is that RPCReturnMap is thatSendRPC()
updates the map here and here, but it's also updated here inConsumeRPCReturnLoop()
.Currently
ConsumeRPCReturnLoop()
function services RPC returns when acting as a client. To fix this problem, I'd suggest expandingConsumeRPCReturnLoop()
to handleSendRPC()
logic as well. We should probably rename the function toRPCClientLoop()
to match the expanded functionality.The existing loop uses
range
to service a single channel. Since the new loop would service multiple channels, it would need to useselect
instead ofrange
.This is strictly a change to
koinos-mq-golang
internals. TheSendRPC()
interface used by callers will remain the same, howeverSendRPC()
will now work like this:SendRPC()
packages its args in a structSendRPC()
sends the args struct toRPCClientLoop
using a channelRPCClientLoop
executes the logic that was inSendRPC()
pre-refactoringRPCClientLoop
packages result/err in a struct and sends the struct back using a channelSendRPC()
gets the result/err struct from a channel and returns to the callerBasically the same logic as before happens, but now all of the code that updates a consumer's
RPCReturnMap
happens in a single goroutine. ActuallyRPCReturnMap
could be made a private variable ofRPCClientLoop
to enforce this.Here's the backtrace: