Anatoly Moskovskynojavaфигня этот ваш asio

он даже близко не умеет вот это: https://en.wikipedia.org/wiki/Reliable_multicast

от слова вообще никак!
Ну мало ли чего там нет. Надо еще доказать что это нужно хотя бы 10% приложений на С++.
Тогда оно обязательно там появится.
А пока востребованность на уровне шума.
Модератор: Отредактировано

д0knojavaпропущено...


слишком большие расходы на сооружение pipeline и переключения контекстов при обработке.
решение так себе, чисто чтоб tftp гонять, не более.

кроме того, xinetd как монитор процессов никуда не годится, ибо тебе за помершими нужно всякий мусор подчищать, далеко не всякая операционка умеет это делать сама (к примеру чистить таблицу читающих транзакций в LMDB).

в epoll/kqueue/libevent в нити диспечере и нитях обработчиках у тебя будет тоже самое
а разница между межнитевым и межпроцесным взаимодействием в совеменных процах и ОС
минимальна .

Модератор: Отредактировано

вообще-то в epoll/kqueue/libevent двигается весьма простая мысль - что одного треда хватит на всё. вообще на всё.
все эти ваши треды отпадают как абсолютно бесполезные и ненужные в их концепции.

а так да, ты прав - fork() по факту приведен к clone(), создание треда тоже идет через этот-же clone()

другое дело - чуваки из libevent они идеалисты, затачиваться на то, что все соединения выживут в одном процессе и ни один дятел не отправит этот процесс в core - это хорошо лишь для nginx/haproxy, где код пишется системный и очень медленно, и высматривается сотнями часо-глаз.

а для write-only прикладника такой подход абсолютно не годится


и вот тут вступает в дело ... zero-copy, но... это отдельный вопрос, как его правильно дружить со стоящим на входе haproxy балансером.

но xinetd на ноде - нет, это лишний и ненужный костыль.

Anatoly Moskovskynojavaвообще-то в epoll/kqueue/libevent двигается весьма простая мысль - что одного треда хватит на всё. вообще на всё.
все эти ваши треды отпадают как абсолютно бесполезные и ненужные в их концепции.
За исключением того что можно разные сокеты на один порт забайндить, каждый из своего потока, и получить помимо epoll еще и бесплатное масштабирование по потокам, вместо возни с процессами.

да да да, ты я смотрю и тут очень великий спец

только одно ты недочитал, теоретик:
авторThe other noteworthy point is that there is a defect in the current implementation of TCP SO_REUSEPORT. If the number of listening sockets bound to a port changes because new servers are started or existing servers terminate, it is possible that incoming connections can be dropped during the three-way handshake.

а так да, очередной раз "блеснул" знанием. еще чего напишешь?

Anatoly MoskovskyИзопропилно проблема аварийного завершения процесса никак не снимается

Всё равно "возиться" с процессами нужно
Перезапуск упавшего процесса - это десяток строк кода, в который не заглядывают десятилетиями.
Это не возиться.

я верил в тебя, ты таки написал это!

а еще кроме перезапуска нужно озаботиться о недопущении слишком частого перезапуска.
отдельно нужно собирать статистику по дочерним процессам - кто там чем занят, не заняли ли он чем-то слишком долго (его нужно принудительно прибивать или нет), а еще нужно вопросы hot-patch решать, с grace терминацией текущих сессий, а еще вопрос DR switch-over..

стоп, мы на ночь глядя будем букварь по мониторингу процессов читать?

10 строчек, да да. печеньки были невкусные?

Anatoly Moskovskynojavaтолько одно ты недочитал, теоретик:
пропущено...


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

да ты что? и что там там будет хуже, господи? подсказка для совсем неопытных - на входе стоит haproxy или nginx. он там стоит всегда, потому что load-balancing делать все равно нужно, лепить реальный ip на каждую ноду бэкэнда - это клиника.

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

правильно - не сказывается.

вот и сказочке конец

Вася УткинAnatoly Moskovskyпропущено...

Ну мало ли чего там нет. Надо еще доказать что это нужно хотя бы 10% приложений на С++.
Тогда оно обязательно там появится.
А пока востребованность на уровне шума.
Вообще-то умеет
Причем очень прозрачно по сравнению с работой с обычным UDP.

что он там умеет? и ledger тоже сам умеет?

да неужели?

Anatoly MoskovskyКроме того это ваш подход дропать процессы на каждый чих.
Существуют и другие подходы, где процесс падает только от крэша.

а еще есть бесконечно зависшие процессы, которые никогда не покрешатся.

но ты продолжай, продолжай, про подходы-то.

д0knojavaпропущено...


да да да, ты я смотрю и тут очень великий спец

только одно ты недочитал, теоретик:
пропущено...


а так да, очередной раз "блеснул" знанием. еще чего напишешь?

вот для этого и нужен xinetd
просто надежно и не нужно шурупы микроскопом забивать :)

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

как entry level "на коленке" он сгодится. а так - создатели systemd смотрят на тебя с недоумением.

Вася Уткинnojavaа когда мне вываливают на голову этот брейнфак с epoll/kqueue/libevent и прочий хлам, да еще трахают мозг с ECONT на write() - хочется кинуть тапком в авторов этого сокет недоразумения.
Так ты же очень интересовался шаблонами, как раз есть boost.asio, без всяких там epoll/kqueue/libevent.

еще раз, тем кто на танке.

epoll/kqueue/т.п. это очень ок и очень хорошо для всего двух типов приложений - 1) nginx и haproxy, где код строго системный, никакое прикладное туда не вписывается.
и где в принципе не может быть ни зависаний, ни креша, ни аномалий, такой себе идеальный мирок в вакууме.


2) единственное место, куда еще их удалось вкрутить - это node.js, просто потому что там по сути изолированная виртуальная javascript машина.

но опять-же - там уже все написано, libev/libevent сами по себе достаточны, никакой там ото бустовской надстройки им и даром не нужно.

от слова вообще.


а т.к. они уже написаны, то ... больше применения этому никакого нет - boost::asio в принципе не приемлем для прикладного программирования, просто потому что неуправляемый прикладной мир (в node.js он управляем) никогда не бывает идеальным - он будет крешиться, зависать, бить память, и т.п.

Anatoly Moskovskynojavaа еще есть бесконечно зависшие процессы, которые никогда не покрешатся.
Ну это смотря кто чем пишет программы ))

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

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