Конкурентность в Go: пять примеров

[grSereger]

для кейса "Ограничение времени выполнения какого-либо процесса" я бы старался не городить горутины, а сделать контекст с таймаутом и внутри process обрабатывался бы отмену контекста.

Бывают конечно кейсы, когда мы используем внешнюю либу, которая не умеет работать с контекстом, но в таком случае текущие решения я бы не позиционировал как best practices.

[perfectgentlemande]

совершенно верно, поэтому и указал в примечании, что можно можно обрабатывать отмену контекста чтением из context.Done()

[RPG18]

В телекоме же придумали алгоритмы типа Leaky bucket для ограничения пропускной способности. Есть https://github.com/uber-go/ratelimit и https://pkg.go.dev/golang.org/x/time/rate

[perfectgentlemande]

Хорошая идея! На одном из проектов (если конечно правильно помню, но ощущение, что правильно) у нас даже видел использование https://github.com/uber-go/ratelimit 

[charypopper]

Кейс 4, Решение 1 - Если добавить sleep в конце main - то сообщение выведется, задача все равно продолжит выполняться - хотя ответ о ее прекращении был получен

[john_soft]

Возможно, я не понял задумки, но почему в примере с ограничением времени процесса. Но задача сформулирована как "не может производить какое-то действие больше 10 секунд."

А выход из функции (прерывание обработки) происходит по таймеру case <-time.After(time.Second * time.Duration(s.AllowedSecondsToProcess)): независимо от премиум аккаунт или нет. Ведь select это не бесконечных цикл обработки, а разовый выбор одного из вариантов