miner: avoid unnecessary work after payload resolution#33943
Conversation
It's a very rare situation which is not expected to happen frequently. Besides, there is no severe consequence of the work generation, the work will be silently ignored if the I feel it's the unnecessary complexity. |
It happened very frequently in the traces I was monitoring; otherwise I wouldn't have bothered. I kept seeing traces where the block was delivered on iteration N and the trace would continue for iteration N+1. If you think about it, it makes sense that it happens often. Let's say the miner is working on a block and spends the entire 2 seconds trying to stuff as many transactions as it can into the block. meanwhile the stop signal arrives somewhere in those 2 seconds....then it is a coin flip whether or not the miner goes into that extra iteration after the block has been delivered. |
agreed that it will be silently ignored. this isn't a hill I am going to die on though |
Issue
In
buildPayload(), the background goroutine uses aselectto wait on the recommit timer, the stop channel, and the end timer. When bothtimer.Candpayload.stopare ready simultaneously, Go'sselectpicks a case non-deterministically. This means the loop can enter thetimer.Ccase and perform an unnecessarygenerateWorkcall even after the payload has been resolved.Fix
Add a non-blocking check of
payload.stopat the top of thetimer.Ccase to exit immediately when the payload has already been delivered.