кто-то делал PHP-демоны на базе libevent ?

[полудух]

C этой точки зрения нет никакой разницы между libevent и socket_accept
Оба варианта - бесконечный цикл.

да, но скорость и параллельность запросов?
кстати, точно, я чё-то сразу не просёк, что в stream_socket_accept($socket,-1)
-1 это бесконечнный цикл

мало того, у либевента есть таймеры и сигналы

 

[fixxxer]

http://www.opennet.ru/base/dev/server_way.txt.html (разумеется, надо понимать, что речь идет об i/o bound серверах; ну и текст 12-летней давности, так что, скажем, претензии к epoll давно неактуальны). Libevent - это всего лишь кроссплатформенная обертка над методами обработки состояния дескрипторов, которые разные в разных ОС.

 

[полудух]

http://www.opennet.ru/base/dev/server_way.txt.html (разумеется, надо понимать, что речь идет об i/o bound серверах; ну и текст 12-летней давности, так что, скажем, претензии к epoll давно неактуальны). Libevent - это всего лишь кроссплатформенная обертка над методами обработки состояния дескрипторов, которые разные в разных ОС.

строго говоря, iptables это кроссплатформенный модуль управления для netfilter
зато как удобно

 

[fixxxer]

Ага, особенно удобно внезапное включение conntrack банальным просмотром iptables -L.

nftables куда удобнее. Жаль, пока что еще не везде и не всё.

 

[полудух]

Ага, особенно удобно внезапное включение conntrack банальным просмотром iptables -L.

да он и так в каждом наборе правил есть

 

[AnrDaemon]

Ага, особенно удобно внезапное включение conntrack банальным просмотром iptables -L.

Зачем включать то, что и так включено?
Самое первое правило
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

 

[полудух]

Самое первое правило

у меня первое правило это lo
потом идут инвалиды и прочие дропы
а только потом accept

 

[fixxxer]

Задачи, внезапно, бывают разные.

А с коннтреком просто забавен квантовый эффект наблюдателя

 

[AnrDaemon]

у меня первое правило это lo
потом идут инвалиды и прочие дропы
а только потом accept

Зачем насиловать процессор? На коннтреке отсекается львиная доля пакетов, и в остальные правила попадает только то, что там может застрять.
А lo идёт вторым правилом.
Инвалиды да, можно поставить перед коннтреком. Даже нужно. Но меня пока не парит. Нет ни нагрузки такой, ни сервисов таких, чтобы как-то на работу повлиять.

 

[полудух]

Во времена одного ядра тоже говорили про параллельность, но ядро то одно.
Если у вас блокирующие долгие операции, то вам никакой libevent нужен. Делайте обычный accept+fork.

вот, кстати, ibm-щики весьма успешно юзают stream_select для распараллеливания

 

[Breeze]

вот, кстати, ibm-щики весьма успешно юзают stream_select для распараллеливания

сколько можно уже, а? мультитаск не мультипроцессность и тем более не мультипоточность
ни о каком параллелизме у stream_select речи не идет. включи голову, откуда у foreach($read) параллельность?

 

[полудух]

сколько можно уже, а? мультитаск не мультипроцессность и тем более не мультипоточность
ни о каком параллелизме у stream_select речи не идет. включи голову, откуда у foreach($read) параллельность?

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

 

[Breeze]

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

в отличие от тебя да, читатель.
чисто для информации -- proc_open идеологически ничем от fork не отличается, создается новый процесс ОС.
и все это крутится в одном цикле пока не будет что-то там готово.

 

[полудух]

в отличие от тебя да, читатель.
чисто для информации -- proc_open идеологически ничем от fork не отличается, создается новый процесс ОС.
и все это крутится в одном цикле пока не будет что-то там готово.

чукча писатель.
в первом листинге вообще нет proc_open
суть статьи - stream_select, всё на нём завязано

 

[MiksIr]

чукча писатель.
в первом листинге вообще нет proc_open
суть статьи - stream_select, всё на нём завязано

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

 

[Breeze]

чукча писатель.
в первом листинге вообще нет proc_open
суть статьи - stream_select, всё на нём завязано

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

 

[полудух]

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

 

[MiksIr]

программа выполняет несколько задач одновременно попеременно

Когда разницу поймете - на все вопросы свои ответите.
Это не мы спорим, это ты какие-то что-то доказать пытаешься какими-то статьями, не понимая их сути.

 

[AnrDaemon]

Темочке пора в корзиночку, не?

 

[полудух]

программа выполняет несколько задач одновременно попеременно

Когда разницу поймете - на все вопросы свои ответите.
Это не мы спорим, это ты какие-то что-то доказать пытаешься какими-то статьями, не понимая их сути.

это не какая-то статья, а статья от IBM
и это не я доказываю, а она сама за себя говорит

Что, если бы программа могла выполнять несколько задач одновременно? Она завершалась бы лишь за часть того времени, которое необходимо при последовательной работе.

Первый пример
Новая функция stream_select, вместе с несколькими своими друзьями, предоставляет эту возможность. Рассмотрим следующий пример:

подождём, пока я что-то там пойму, ок