Огромный лимит - это какой? В байтох

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

Так в этом и смысл не делать подобные решение изначально. Одни придумали пагинацию, другие придумали блокировку zero cost на запись при достижении лимита. Взять все, занять память и обрабатывать по чайной ложке - это очень-очень плохое решение

Все мы живём в реальном мире. Может человеку уже вот с такими вводными на условный сокет в его сервис могут навалить задач и всё тут.

ну давайте разберемся одна запись в канале - это 8 байт, указатель (можно иначе, но мы же экономим память, да?) сколько записей максимально вы хотите держать в очереди, чтобы эти 8 байт имели значение?

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

Сокет тоже в цикле читать можно (и нужно). При этом клиент может ставить высокие таймауты, зная объем. Не делайте мифическую задачу задачей computer science, это мифическая задача без требований)

Складывать у себя пока следующий сервис лежит это заявка на распределённую очередь

Ещё раз: я не говорю что это всё прямо идеально правильно. Я говорю что вопрос технически корректный и я могу представить реальные ситуации в которых такое может захотеться.

для миллиарда надо уже durable очередь советовать (что и было сделано) поэтому вопрос о пиковом наполнении очереди - он ключевой для поиска ответа. но именно на этот вопрос наш друг отвечать отказался (потому, что он бы сказал - миллион, и я бы спросил в ответ, почему нельзя аллоцировать канал на 2 миллиона указателей, это всего 16MB памяти)

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

Я тоже могу себе представить миллион таких ситуаций. И в большинстве из них наилучшее решение будет другое (в го, по крайней мере)

Он в качестве размера написал - сколько влезет в принципе до прихода OOM. Я это как потенциальные гигабайты расцениваю.

Без циферок вопрос некорректный. Банально памяти может не хватить все положить в RAM и придется через буфер складывать на диск. Думали когда-нибудь почему вообще появилось поняите буфер?

А какой вопрос то? Готовая либа, реализующая конкретный кейс?

удалось попасть в мейл?)

В 540 гигабайт памяти влезет, ммм, 67 миллиардов указателей. Или 540 миллионов залоченных горутин

Это какая-то тонкая шутка, но я не понял)

Да. Поэтому нормально отвечать "Вот такое есть например, хотя в целом подход некрасивый,лучше сделать вот так". А не кидаться какашками взаимно. В 99% таких случаев никто не дурак, просто все друг друга не поняли и все посчитали остальных дураками.

да просто спросил, ты наверное тоже собеседовался в мейл но я забыл

Ааа, не, ты обознался)

Кидаться какашкми и орать про computer science начали не мы) Решения очевидно нет, но чтобы выбрать из чего есть (nats, redis, amqp* и тд) нужно хотя бы масштабы понимать

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

Корректный. Я вижу конкретный вопрос с конкретным желанием нелимитированного буфера под очередь в памяти без преаллокации. Выделять пока не придет ООМ. Правильный подход или нет - вопрос десятый и тут нужно не писать в ответ лаконичное: "у вас всё неправильно!", а писать как дополнительное замечание "лучше было бы сделать вот так".

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

тогда их можно просто дропать, правда? опять не нужна очередь...

Можно дропать да, но хотелось бы best effort по доставке сделать и не дропать пока есть вариант не дропать.

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

А сколько влезет в систему на момент возникновения такой ситуации, такого и размера. Можно этот лимит потом в конфиг вынести или через cgroups ограничить и ошибки аллокации обрабатывать по факту.

и? почему не буферизованный канал-то?

Потому что аллоцировать много памяти с мыслью "ну вот мало ли раз в год придется поскладывать данные в памяти" тоже такая себе затея.

Уж лучше переаллоцировать на ходу многократно. Гениально блин) (нет)

много - это сколько? коллега, вы, пожалуйста, воздержитесь от использования этого аргумента в четвертый раз, пока не ответите на этот вопрос

16 гигабайт. Но нужны они потенциально раз в два года. А в норме очередь вообще пустая.

это на другой вопрос ответ. я спросил - сколько элементов в очереди в пике

Допустим 500 миллионов в пике раз в два года потенциально. Но в нормальной ситуации обычно ноль.

а сообщение одно какого размера?