Анатомия каналов в 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? Там всего три доступных метода добавить, завершить и ждать..

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

[agoalofalife]

Теперь мы можем только считывать данные из этого канала, а любые операции чтения приведут к аварийному завершению программы со следующей ошибкой
Скажите вы тут подразумевали слово записи?

[abratko]

Для понимания концепта блокировки первая операция отправки c <- “John” будет блокирующей, и другая горутина должна будет считать данные из канала, следовательно greet горутина будет запланирована планировщиком. Затем первая операция чтения будет неблокируемой, поскольку присутствуют данные для чтения в канале c. Вторая операция чтения будет блокируемой, потому что в канале c отсутствуют данные, поэтому планировщик переключится на main горутину и программа выполнит закрытие канала close©.

Здесь ошибка. В примере у канала есть буфер. Горутина запланируется, потом сразу будет запись в канал. Запись не блокирующая, потому что канал с буфером. Этому канал сразу закроется и сразу попытка записи в канал. Поэтому паника. Горутина ничего не прочитает из канала, потому что блокировки не было и переключения выполнения не было. А вот если сделать канал без буффера, будет так как описано.