Comments 6
для кейса "Ограничение времени выполнения какого-либо процесса" я бы старался не городить горутины, а сделать контекст с таймаутом и внутри process обрабатывался бы отмену контекста.
Бывают конечно кейсы, когда мы используем внешнюю либу, которая не умеет работать с контекстом, но в таком случае текущие решения я бы не позиционировал как best practices.
В телекоме же придумали алгоритмы типа Leaky bucket для ограничения пропускной способности. Есть https://github.com/uber-go/ratelimit и https://pkg.go.dev/golang.org/x/time/rate
Хорошая идея! На одном из проектов (если конечно правильно помню, но ощущение, что правильно) у нас даже видел использование https://github.com/uber-go/ratelimit
Кейс 4, Решение 1 - Если добавить sleep в конце main - то сообщение выведется, задача все равно продолжит выполняться - хотя ответ о ее прекращении был получен
Возможно, я не понял задумки, но почему в примере с ограничением времени процесса. Но задача сформулирована как "не может производить какое-то действие больше 10 секунд."
А выход из функции (прерывание обработки) происходит по таймеру case <-time.After(time.Second * time.Duration(s.AllowedSecondsToProcess)): независимо от премиум аккаунт или нет. Ведь select это не бесконечных цикл обработки, а разовый выбор одного из вариантов
Конкурентность в Go: пять примеров