From d1f1fe075289e709062e8d62c73078f30fb17c5a Mon Sep 17 00:00:00 2001 From: Dave Collins Date: Sat, 21 Sep 2013 09:23:26 -0500 Subject: [PATCH] Revert "Send notification in their own goroutine." After discussion with others and thinking about the notification channel some more, we've decided to leave it up to the caller to quickly handle notifications. While it is true that notification should be handled quickly to not block the chain processing code unnecessarily, launching a goroutine in chain means the notifications are no longer necessarily in order. Also, if the caller is not properly handling the notifications, the goroutines end up sicking around forever. By leaving it up to the caller to quickly handle the notification or launch a goroutine as necessary for the caller, it provides the flexibility to ensure proper notification ordering as well as control over other things such as how to handle backpressure. --- notifications.go | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/notifications.go b/notifications.go index 4ad7b376..51ac0c8a 100644 --- a/notifications.go +++ b/notifications.go @@ -71,9 +71,7 @@ func (b *BlockChain) sendNotification(typ NotificationType, data interface{}) { return } - // Generate and send the notification asynchronously. - go func() { - n := Notification{Type: typ, Data: data} - b.notifications <- &n - }() + // Generate and send the notification. + n := Notification{Type: typ, Data: data} + b.notifications <- &n }