Здравствуйте. Кто-нибудь пользуется какой-нибудь production-ready concurrent queue (буферизованный канал не

подходит т.к. он жестко ограничен)?

Основные наверное это RabbitMQ (фиговая кластеризация) и Kafka (не совсем очередь, но с хорошим кластером), но есть еще куча аналогов

Имеется в виду замена буферизованному каналу на уровне языка

хм, а чем вам канал не угодил?

Перечитайте пожалуйста вопрос

я прочитал и все равно не понял, чем канал жестко ограничен?

При создании канала вы задаете capacity. Менять её нельзя.

да, а чем это вам мешает? можно заранее задать достаточно большую capacity при необходимости

Можно все делать заранее. Заранее закупить самый мощный сервер на земле с петабайтами оперативной памяти и установить емкость канала в триллион записей. Вопрос не про это.

Вы можете описать задачу, которую вы решаете? Пока что выглядит как преждевременная оптимизация

А зачем вам триллион записей в канале? Вы что-то, видимо, не понимаете в его работе

так в буферизированном канале просто создается массив определенного типа. для конкуррентности используюется интернал реализация мьютекса, которая мб дает некий буст по скорости. думаю, что слайс, прикрытый обычным sync.Mutex даст то, что вы хотите, с незначительным проседанием по производительности

Мне кажется что можно неплохо так влететь при реализации своего канала вот так вот в лоб, как минимум он может сожрать бесконечное количество памяти:)

а буферизированный канал на большое число элементов не сделает то же самое?

Ну я скорее имел ввиду правильную очистку нижележащего слайса при продолжительном использовании

Это все замечательно, но это нужно программировать. Вопрос и был есть ли готовые решения.

Есть менеджеры очередей из которых можно забирать прикладом данные. RabitMQ тот же... Не думаю, что эту часть стоит реализовывать в самом прикладе. MQха сгладит пиковые нагрузки и выступит в качестве буфера.

Конечно есть, тут скорее вопрос с выяснением ваших требований. Если загуглить golang concurrent queue, то выпадет много всего, например https://github.com/enriquebris/goconcurrentqueue в виду кажущейся простоты, я бы все же сунулся в этом сам. Но и либы использовать конечно привествуется.

Да, это видел, не подошло. Спасибо.

а чем не подошло-то?

Дельный коммент. Да, вы правы, что слайс с его преаллокацией проигрывает например связному списку. Но опять в сравнении просто с массивом в канале, все равно лучше :)

каналы прекрасны тем, что с ними напрямую взаимодействует шедулер. и заблокированные на каналах горутины снимаются с очереди на выполнение. самописное решение можно заставить делать так же, но - с помощью уже двух каналов. надо ли?

Да, доработка для шедулера с каналами ценна. Нельзя ли ее достичь ручными вызовами Gosched в самописном коде? я не берусь писать самодельную очередь, просто интересно

не, не получится. горутина должна как-то заблокироваться на канале, если в нем ничего нет, например.

горутина может заблокироваться на mu.Lock() после проверки, и будет то же самое?

а разблокировать ее как?