Eliminate deadlock by using generate instead of setgenerate RPC
#88
Conversation
|
Thanks. I'll trigger a new Travis build once btcsuite/btcd#407 has landed. |
|
@tuxcanfly Can you review this since you're far more familiar with the btcsim code than I am? |
|
Sure, on it. |
| @@ -428,6 +428,12 @@ func (com *Communication) estimateTpb(tpbChan chan<- int) { | |||
| func (com *Communication) Communicate(txCurve map[int32]*Row, miner *Miner, actors []*Actor) { | |||
| defer com.wg.Done() | |||
|
|
|||
| go func() { | |||
There was a problem hiding this comment.
I think we can do without the goroutine since we're waiting for the blocks in the for select below anyway.
There was a problem hiding this comment.
OK, I see that generate is blocking, unlike setgenerate so actually we could do away with the notifications handlers to wait for the miner. Let me check that.
|
Since we don't need a peer to start mining, we can probably remove the setup for adding a node to serve as the peer. |
|
What's the status of this? |
|
At the very least, it needs a rebase since it doesn't have the latest changes needed by btcrpcclient. |
|
This could be better handled since |
No description provided.