N>Вы, мысля масштаба WhatsApp и Facebook, не понимаете, что при маленькой команде (а она никогда не выходила за 10 человек, из которых собственно проблемы транспорта понимали максимум 3, а ведь есть и другие задачи)

Вы, вероятно, не поверите, но в масштабе WhatsApp "проблемами транспорта" занимается 1.5 человека. Эти же 1.5 занимаются еще и системой сборки, и багами в BEAM'е, и еще много чем кроме.

N> И общей проблемой, наверно, 99% взаимодействий является то, что если сообщение потеряно, то его надо перепосылать. Множественные "трубы" тут ничего не дадут.

Возвращемся к exactly once delivery, а также множественным реализациям tcp over tcp. Ох сколько их я видел

N>Ага, то есть хорошо было бы ещё и в binary их перепаковывать, причём размера не меньше сколько-то (с какого размера там включается оптимизация)? И это на внутреннем взаимодействии (внутри одной ноды)? Вам не кажется, что это слишком большие требования для простой задачи?

По условию задачи, вы пользуетесь gen_tcp:send(). Он на вход принимает binary(). То есть вы совершенно точно уже пакуете ваши структуры в binary(). Именно это (и только это) я и предлагаю делать в отдельном процессе, задача которого — заниматься сериализацией, и ничем более.
Вы можете честно признаться, что такое решение не пробовали?

Добавлю, что такие решения начинают появляться только после осознания аналогии между экземпляром класса в С++ и процессом в Эрланге. Равно как класс "труба" не занимается сериализацией, так и в эрланге, процесс "труба" занимается только трубой.

N>Я посмотрел, спасибо. Великолепный английский как для родного русского — завидую...

Спасибо. К сожалению, цена — некоторая потеря умения писать и говорить по-русски.

N> остаётся определить, с чего именно начинать измерения и проверки, а это получается только с опытом в теме.

И об этом я тоже говорю. Начинать надо с вопросов "зачем" (почему). До тех пор, пока не достигнем корня проблемы. К сожалению, подобные выступления всегда очень ограничены по времени, поэтому я лишь очень вскользь прошелся по critical thinking (думаю, упоминал critical thinking cards, fallacies и т.п.). Конечно, опыт важен, но еще важнее умение думать. Зрить в корень.

N>Дададад. "Отвечал". То есть шло бы обратно сообщение, которое вставало бы в конец очереди. Вы это серьёзно?

Я же говорю, что видел и более странные side channel, — не значит, что они работали как ожидалось авторами. Но, однако, из-за selective receive optimisation, — иногда и работало.

N>И вы тут то ли намеренно ёрничаете, то ли явно не в курсе про volatile в многонитевом окружении?

Я же даже поставил большой зеленый смайл. Возможно, стоило вставить смайл с "сарказмом".

N>Перескажите словами, что происходит, если хотите понимания.

Классика жанра, которую так же легко воспроизвести для вашего случая (один процесс накапливает binary buffer, второй шлет данные). Там сделана оптимизация, что процесс "трубы" перед тем как отправить данные в трубу спрашивает у сериализующего процесса "а не пришли ли еще данные". Когда данные идут непрерывно, получается бесконечный цикл, рано или поздно выедающий всю память.

N>Как вы через супервизоры будете снимать набор количественных показателей работы приложения (текущие уровни, счётчики, и всё такое)? Или вы под словом "мониторинг" тут понимаете только

См. выше, про "зрить в корень". Уровни, счетчики, "все такое" — каким это образом используется? Какие решения принимаются?

N>Или опять ETS, который вы хотели бы устранить?

Для простых счетчиков ETS уже не модно. Современные реализации обычно что-то вроде ecount, или вовсе telemetry (open telemetry)

N>Я думаю, последние 20 лет вопрос "какие действия принимаются..." на основе счётчиков событий (банально, полученных/посланных сообщений по выбранной классификации, и всё такое) — просто не должен озвучиваться. Вопрос должен быть — делаются ли эти действия вообще и правильные ли они.

Не соглашусь. Это как раз самый что ни на есть важный вопрос — "как мы используем собираемые данные". Понимаю, что дальше будет вопрос "а что нам это стоит" и "с таким ценником, а стоит ли".

N>1) Речь идёт об управлении конкретным процессом и его контроле через единственный, по вашим же правилам, разрешённый интерфейс в виде асинхронно поступающих сообщений. Канал через ETS не разрешаем.
N>2) Надо управлять этим процессом, включая регулирование параметров (оперативное! ждать секунды, пока он прочтёт сообщение, нельзя).
N>3) Увы, gen_call иногда (а может, и всегда) нужен из-за того, что на нём работает некоторый интерфейс, который мы менять не можем.

Здесь я не могу привести ничего другого, кроме как притчи:

Мастера боевых искусств спросили, как он поступит, если переходя узкий подвесной мост над пропастью, заметит засаду спереди и сзади? Мастер несколько раз сказал, что он не понимает заданного вопроса. В конце концов ученики потеряли терпение:
— Что тут непонятного? Ты на мосту, ты не можешь идти вперед, ты не можешь вернуться, ты не можешь убежать, ты не сможешь справиться с таким большим числом врагов!
— Я не понимаю, как я смогу оказаться в таком положении? — был ответ.

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

N>И снова от вас никакой конкретики, только "стройная модель" (стройность которой на самом деле ничуть не испортит введение нескольких очередей) и ссылка на какие-то посторонние случаи, про которые ничего не известно.

Потому что ваш вопрос не является вопросом, а явлется тем самым "спереди вражеские воины, и сзади, а вы на подвесном мосту". Вы сами ставите такие условия, а потом запрещаете ровно то, о чем я так давно уже говорю — "challenge your assumptions".

N>А почти все задачи начинаются с "быстрее сделать", построить MVP или какой там будет его аналог. И вот тут становится критичным, что люди, которые не разбираются во всех тонкостях, должны поднять и сопровождать проект на начальной стадии.

Вернулись к "учиться работать с экскаватором некогда, потому что нужно копать". Не вижу смысла заходить на третий круг. Понимаю ваши рассуждения о том, что для освоения радикально новых концепций требуется больше времени, чем просто перейти с очередного С+ на С++ и на С+++.

Еще раз сетую на недостатки существующей системы образования. Это заколдованный круг, когда кто-то уже научившийся императивному программированию с идиомой "call" думает, что так легче научить других. Нет, не потому, что так легче, а потому что он уже так научился. Это для него, кто уже с детства был так научен. И что он делает дальше, просто продолжает делать то, чему его научили. Тот самый fixed mindset. Который так мешает многим.

N>То есть пробовать не хотите? Спасибо, Ч.Т.Д.

Мне не нужно пробовать. Я уже объяснил, что знаю, как оно устроено и как работает. Это ключевые умения разработчиков — не просто "пробовать" и говорить "что-то где-то как-то не так", а разбираться в том, *ПОЧЕМУ* оно так.

N>А для практического применения я буду выбирать средства с максимально пологой кривой обучения (будем уже держаться в рамках этого термина), потому что полученные продукты будут выживать даже при полной смене команды.

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

Могу лишь отметить, — кто не рискует, тот не пьет шампанское