Спасибо за развернутый комментарий! Особенно за то, что расписали по пунктам (это хорошо читается)
Согласен с моментом насчет контекста. Поскольку это обучающая статья, я убрал select'ы по контексту. Своим студентам, когда работал на курсе от МТС я давал пример с контекстами. Но здесь посчитал, что это перегрузит обучающую статью.
1. Сделал максимально простым, но читаемым (чтобы видно было, что "семафор"). Вообще необязательно даже отдельный тип делать, можно каналом ограничиться. Кстати, если у вас есть под рукой реализация такая которая нравится можете скинуть)
2. Согласен
3. Согласен. В бою я обычно вешаю контекст везде. В этом случае всегда будет кейс который снимает блокировку висящих горутин и завершает этот процесс.
4. Я так понял, это связано с 3-м: мы гарантируем, что за пределами функций не будет утечек. В таком случае согласен.
Вот меня мучил тот же вопрос, когда я гуглил реализации семафоров когда-то. Поэтому когда я решал аналогичную задачу, я делал это именно вторым способом. Горутины нет смысла плодить бесконечно, это забьет ресурсы, поэтому для меня в тот момент было логичным ограничить как раз количество созданных горутин.
Но я не отрицаю, что первый способ нужен в рамках каких-нибудь других примеров (было бы интересно узнать для каких). И из плюсов я заметил, что не будет ситуации что ты воркерпулу из большого числа заранее созданных висящих горутин скормишь пару задач. Но это условный плюс.
при закрытии sgnlCh по факту не происходит уже чтения из outputCh. Это значит, что первый кейс (case outputCh <-) к моменту закрытия sgnlCh будет в блокировке всегда в данном примере.
Хорошая идея! На одном из проектов (если конечно правильно помню, но ощущение, что правильно) у нас даже видел использование https://github.com/uber-go/ratelimit
>В чем конкретный плюс redpanda
в универсальности, не обязательно использовать с Кафкой и кликхаусом. В статье есть ссылка на то, с чем дружит Редпанда:
https://docs.redpanda.com/redpanda-connect/components/inputs/about/
https://docs.redpanda.com/redpanda-cloud/develop/connect/components/outputs/about/
Спасибо за развернутый комментарий! Особенно за то, что расписали по пунктам (это хорошо читается)
Согласен с моментом насчет контекста. Поскольку это обучающая статья, я убрал select'ы по контексту. Своим студентам, когда работал на курсе от МТС я давал пример с контекстами. Но здесь посчитал, что это перегрузит обучающую статью.
1. Сделал максимально простым, но читаемым (чтобы видно было, что "семафор"). Вообще необязательно даже отдельный тип делать, можно каналом ограничиться. Кстати, если у вас есть под рукой реализация такая которая нравится можете скинуть)
2. Согласен
3. Согласен. В бою я обычно вешаю контекст везде. В этом случае всегда будет кейс который снимает блокировку висящих горутин и завершает этот процесс.
4. Я так понял, это связано с 3-м: мы гарантируем, что за пределами функций не будет утечек. В таком случае согласен.
Вот меня мучил тот же вопрос, когда я гуглил реализации семафоров когда-то. Поэтому когда я решал аналогичную задачу, я делал это именно вторым способом. Горутины нет смысла плодить бесконечно, это забьет ресурсы, поэтому для меня в тот момент было логичным ограничить как раз количество созданных горутин.
Но я не отрицаю, что первый способ нужен в рамках каких-нибудь других примеров (было бы интересно узнать для каких). И из плюсов я заметил, что не будет ситуации что ты воркерпулу из большого числа заранее созданных висящих горутин скормишь пару задач. Но это условный плюс.
при закрытии
sgnlChпо факту не происходит уже чтения изoutputCh. Это значит, что первый кейс (case outputCh <-) к моменту закрытияsgnlChбудет в блокировке всегда в данном примере.интересный кейс, спасибо!
Спасибо!
А если это не NDA, то можно абстрактно расписать кейс?
Спасибо! Видел этот пакет, даже пользовался пару раз)
Хорошая идея! На одном из проектов (если конечно правильно помню, но ощущение, что правильно) у нас даже видел использование https://github.com/uber-go/ratelimit
совершенно верно, поэтому и указал в примечании, что можно можно обрабатывать отмену контекста чтением из context.Done()