9c18c3d9a4
In this commit, we fix a lingering bug related to the way that we deliver block epoch notifications to end users. Before this commit, we would launch a new goroutine for *each block*. This was done in order to ensure that the notification dispatch wouldn’t block the main goroutine that was dispatching the notifications. This method archived the goal, but had a nasty side effect that the goroutines could be re-ordered during scheduling, meaning that in the case of fast successive blocks, then notifications would be delivered out of order. Receiving out of order notifications is either disallowed, or can cause sub-systems that rely on these notifications to get into weird states. In order to fix this issue, we’ll no longer launch a new goroutine to deliver each notification to an awaiting client. Instead, each client will now gain a concurrent in-order queue for notification delivery. Due to the internal design of chainntnfs.ConcurrentQueue, the caller should never block, yet the receivers will receive notifications in order. This change solves the re-ordering issue and also minimizes the number of goroutines that we’ll create in order to deliver block epoch notifications. |
||
---|---|---|
.. | ||
bitcoind.go | ||
driver.go |