Анатомия каналов в Go

[bouncycastle]

Ожидал увидеть статью про то как устроены каналы «под капотом» (анатомия же), но все равно спасибо за статью.

[alex89v]

На самом деле такие статьи уже есть, что на хабре, что на medium, я включу их в дополнение к статье.

[KOTaSYS]

отличная статья. не знаю как кому, но то что мне сейчас надо. спасибо!

[NeverIn]

Много опечаток, типа
Если изменить time.After(2 * time.Second) на time.After(2 * time.Second)

[buendia]

Про concurrency-паттерны есть хорошая статья на go.dev: Go Concurrency Patterns: Pipelines and cancellation. Отлично заходит как дополнение к этой.

[dmitry_dvm]

Спасибо за статью. Можете привести пару примеров, когда нужен именно буферизированный канал?

[Skybladev2]

В разделе Работа с несколькими горутинами вывод программы будет другой, на 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

[VladimirFarshatov]

Не разобран кейс Fan out (быстрый писатель + несколько медленных читателей с канала) на предмет падения читателей по неустранимой ошибке. Писатель, при падении всех читателей по неустранимой ошибке, просто повиснет на переполненном буфере канала. А по-хорошему, его надо бы как-то извещать, что читать больше некому..

а) Как вариант, аварийно закрывать канал последним читателем - не проходит, т.к. проверка

_,ok := <- chToWrite; !ok -- приведет к потере данных процессом считывания из канала.

б) Проверка перед записью, что буфер полон не может сигнализировать о потере читателей.

в) организовывать встречный канал ошибок .. ну такое себе.

г) проверять через wggroup? Там всего три доступных метода добавить, завершить и ждать..

А кейс достаточно распространенный.