потоков, когда есть список задач (который может пополняться). И надо предусмотреть завершение горутин.
Решение в лоб: запускаем X горутин с общим каналом, который будет прослушиваться, и задачи внутрь горутины будут поступать через него.
Как при этом сделать завершение горутин? Некрасивое решение в лоб: еще передать второй канал в горутину, внутри неё юзать select, а когда мы хотим все остановить - посылаем в неё количество сообщений по числу горутин. Каждая горутина при получении сообщения из стоп-канала просто закрывается, и её соседи берут следующие сообщения. Выглядит максимально грязно. Какие есть альтернативные решения?
Посмотрите библиотеку context, может это то, что вам нужно
закрой общий канал
на самом деле это оч комплексная задача, и зависит от того, как именно горутины поддерживать, но в основновном можно обходиться context.Context, чаще всего это самый правильный способ. Но не всегда, например иногда необходимо передавать какие-нибудь данные в горутину, так что зависит от ситуации
Посмотрел, я так понимаю. что функция горутины внутри устроена так же, как и в моем примере, с селектом по двум каналам. Но при этом мне не надо просто самому явно в тот канал посылать определенное количество значений, спасибо.
Хм, j, more := <-jobs выглядит еще проще
Если в горутине цикл range по каналу, то достаточно будет просто этот канал закрыть при завершении программы, цикл завершится и горутина тоже, но только когда в канале не останется элементов
Ага, спасибо, в целом понял. Если мне надо будет больше контроля над горутинами, то контекст, но закрытие канала мне поможет с примитивной постановкой задачи, когда горутины не надо закрывать преждевременно по какому-либо условию.
А если мне надо иметь изменяемое число горутин для обработки очереди, то есть ли какие-то готовые решения, которые мне следует знать?
Тогда думаю можно обойтись и без контекста, будет более лаконично
Запускайте, сколько надо, да и все Паттерн worker pool совсем не обязателен к применению
Обсуждают сегодня