Комментарии 8
Если изменить time.After(2 * time.Second) на time.After(2 * time.Second)
Про concurrency-паттерны есть хорошая статья на go.dev: Go Concurrency Patterns: Pipelines and cancellation. Отлично заходит как дополнение к этой.
Спасибо за статью. Можете привести пару примеров, когда нужен именно буферизированный канал?
В разделе Работа с несколькими горутинами вывод программы будет другой, на https://go.dev/play/p/6wdhWYpRfrX он правильный:[main] main() started
[main] sent testNum to squareChan
[square] reading
[main] resuming
[main] sent testNum to cubeChan
[cube] reading
[main] resuming
[main] reading from channels
[main] sum of square and cube of 3 is 36
[main] main() stopped
Не разобран кейс Fan out (быстрый писатель + несколько медленных читателей с канала) на предмет падения читателей по неустранимой ошибке. Писатель, при падении всех читателей по неустранимой ошибке, просто повиснет на переполненном буфере канала. А по-хорошему, его надо бы как-то извещать, что читать больше некому..
а) Как вариант, аварийно закрывать канал последним читателем - не проходит, т.к. проверка
_,ok := <- chToWrite; !ok -- приведет к потере данных процессом считывания из канала.
б) Проверка перед записью, что буфер полон не может сигнализировать о потере читателей.
в) организовывать встречный канал ошибок .. ну такое себе.
г) проверять через wggroup? Там всего три доступных метода добавить, завершить и ждать..
А кейс достаточно распространенный.
Анатомия каналов в Go