LINUX.ORG.RU

История изменений

Исправление Vic, (текущая версия) :

Возможно, вам подойдут именованные каналы, они очень похожи на файлы, но их содержимое, как и у обычных каналов, находится в ОЗУ ОС.

Вот тут примерчик есть с сервером и клиентом: ссылка #1 на opennet.ru

На сколько я понял, они так же обладают атомарными операциями для не больших порций данных: ссылка #2 на opennet.ru

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

PS. Плюс соглашусь с остальными, что архитектурно 10к процессов, которые должны все вместе быстро обрабатывать мелкие данные – это не про скорость и не про оптимальное использование процессора. Для достижения хороших скоростей в прикладных программах (user space) нужны специальные методы, включая буферизацию поступающей информации в «бОльшие» порции (например, через промежуточную БД в ОЗУ) и только затем передавать полученные порции на обработку. Иначе, у вас в любом случае все процессорное время съест межпроцессный обмен, нежели полезная работа.

Исправление Vic, :

Возможно, вам подойдут именованные каналы, они очень похожи на файлы, но их содержимое, как и у обычных каналов, находится в ОЗУ ОС.

Вот тут примерчик есть с сервером и клиентом: ссылка #1 на opennet.ru

На сколько я понял, они так же обладают атомарными операциями для не больших порций данных: ссылка #2 на opennet.ru

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

PS. Плюс соглашусь с остальными, что архитектурно 10к процессов, которые должны все вместе быстро обрабатывать мелкие данные – это не про скорость. Для достижения хороших скоростей в прикладных программах (user space) нужны специальные методы, включая буферизацию поступающей информации в «бОльшие» порции (например, через промежуточную БД в ОЗУ) и только затем передавать полученные порции на обработку. Иначе, у вас в любом случае все процессорное время съест межпроцессный обмен, нежели полезная работа.

Исправление Vic, :

Возможно, вам подойдут именованные каналы, они очень похожи на файлы, но их содержимое, как и у обычных каналов, находится в ОЗУ ОС.

Вот тут примерчик есть с сервером и клиентом: ссылка #1 на opennet.ru

На сколько я понял, они так же обладают атомарными операциями для не больших порций данных: ссылка #2 на opennet.ru

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

PS. Плюс соглашусь с остальными, что архитектурно 10к процессов, которые должны все вместе быстро обрабатывать мелкие данные – это не про скорость. Для достижения хороших скоростей в прикладных программах (user space) нужны специальные методы, включая буферизацию поступающей информации в «бОльшие» порции и только затем передавать полученные порции на обработку. Иначе, у вас в любом случае все процессорное время съест межпроцессный обмен, нежели полезная работа.

Исходная версия Vic, :

Возможно, вам подойдут именованные каналы, они очень похожи на файлы, но их содержимое, как и у обычных каналов, находится в ОЗУ ОС.

Вот тут примерчик есть с сервером и клиентом: https://www.opennet.ru/docs/RUS/lpg/node6.html#SECTION00730000000000000000

На сколько я понял, они так же обладают атомарными операциями для не больших порций данных: https://www.opennet.ru/docs/RUS/lpg/node6.html#SECTION00724000000000000000

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

PS. Плюс соглашусь с остальными, что архитектурно 10к процессов, которые должны все вместе быстро обрабатывать мелкие данные – это не про скорость. Для достижения хороших скоростей в прикладных программах (user space) нужны специальные методы, включая буферизацию поступающей информации в «бОльшие» порции и только затем передавать полученные порции на обработку. Иначе, у вас в любом случае все процессорное время съест межпроцессный обмен, нежели полезная работа.