4 ms·
They'll get lost when using a non-blocking send with select/default: messages := make(chan string) select { case messages <- "hi": fmt.Prin
by brandur 2y ago
They'll get lost when using a non-blocking send with select/default:
messages := make(chan string)
select {
case messages <- "hi":
fmt.Println("sent message", msg)
default:
fmt.Println("no message sent")
}
The reason you'd use a non-blocking send is to make sure that in the event of one slow consumer that the entire system doesn't slow down.
Imagine a scaled out version of the notifier in which it's listening on hundreds of topics and receiving thousands of notifications. Each notification is received one-by-one using something like Pgx's `ListenForNotification`, and then distributed via channel to subscriptions that were listening for it.
In the case of a blocking send without `default`, one slow consumer that was taking too much time to receive and process its notifications would cause a build up of all other notifications the notifier's supposed to send, so one bad actor would have the effect of degrading the time-to-receive for all listening components.
With buffered channels, a poorly written consumer could still drop messages for itself, which isn't optimal (it should be fixed), but all other consumers will still receive theirs promptly. Overall preferable to the alternative.
- salojoo 2y agoRight, I didn't know it was possible to bypass full channels like that with select/default. Thanks for spelling it out