процесса?
пример с динамическим количеством воркеров
https://play.golang.org/p/kxvsBZM83H5
используйте семафоры
никак если каждый запуск задачи делать push в канал, то можно уменьшить эффективную ёмкость канала, запихнув в него N тикетов а вот с увеличением проблемы
ну свою конкуретную очередь сделать можно если очень сильно хочется
ну можно извернуться и сделать условный канал на 100 (1000) элементов, на старте запулить туда 90 - вот тебе и 10 воркеров. Надо увеличить - вычитываем из канала нужное количество, получаем увеличение.
Можно Но, честно говоря, обычно не нужно, по крайней мере на моей практике сразу нужна бывает персистентность, а значит какой-нибудь NATS или кафка
можно но на атомарных счётчиках получается примерно так же просто, хотя в крайних случаях страдает отзывчивость я обычно делаю так 1. Если ограничение на количество параллельных задач вообще не нужно — обычная waitgroup 2. Ограничение статическое и известно до запуска всех задач — канал пустых структур-тикетов 3. Динамическое ограничение (например шейпинг запросов на сервис) — атомарные счётчики и отменяемый сон на таймерах и мне кажется, что случаи 1 и 2 — это примерно 80% юзкейсов
Обсуждают сегодня