IPC события в одном потоке

zmq, dbus

но сначала всё-таки определиться что посылаешь и зачем :-) Какой-то разброд и шатания - то ли сигналы, то ли сообщения..то ли в один адрес, толи в несколько. и так далее

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

https://zeromq.org/get-started/

заводить отдельный тред и сидеть в блокировке там

есть и асинхронные библиотеки, но там всё равно где-то создается этот отдельный thread.

zmq, dbus

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

но сначала всё-таки определиться что посылаешь и зачем :-)

это я уже!

Какой-то разброд и шатания - то ли сигналы, то ли сообщения..то ли в один адрес, толи в несколько. и так далее

Это я так описал широко: моя цель – не чтоб мне дали ответ что использовать, а послушать что люди об этом думают, кто что слышал, кто что использует. Опыт: был ваш – будет наш!

а чтобы не порождать треды на каждый чих

Тебе жалко что-ли? :) давай обсудим!

например libuv.org (и подобные, их много на вкус и цвет)

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

есть и асинхронные библиотеки, но там всё равно где-то создается этот отдельный thread.

И другого пути нет? Если так: то на кой черт мне эти библиотеки, я и без них могу тред создать и сидеть слушать сокет. 20 строчек делов и тащить ниче не надо и отлаживать проще. Мне главное – надежность и простота. И скорость. И какаво с чаем :) все хочу и нахаляву

sd-dbus достаточно лайтовая и простая. Есть ещё ubus от openwrt, там простой json без типизации.

select() / epoll_wait() + non-blocking fds. Классика. Удивлён что ещё не написАли.

А как ты ещё хотел? Типа, данные из сокета сами собой принимаются и ложатся и ложатся куда-то?

В чём вопрос то тогда, если уже все можешь. С AF_UNIX, SOCK_SEQPACKET можно даже не думать о фреймах – read/write всегда будут получать нужный размер.

Путей 3: сокеты, сигналы, разделяемая память. Последние 2 правильно использовать крайне непросто.

ubus от openwrt

О! Выглядит здорово, спасибо

select() / epoll_wait() + non-blocking fds. Классика. Удивлён что ещё не написАли.

да, оно, держу про запас как один из вариантов

А как ты ещё хотел? Типа, данные из сокета сами собой принимаются и ложатся и ложатся куда-то?

Ну есть же варианты: ждать сигнал, потом выгребать (отделный тред не нужен, плюс селект вот предложили. Все еще не так однозначно! )

В чём вопрос то тогда, если уже все можешь.

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

Путей 3: сокеты, сигналы, разделяемая память

А как через память передать событие? Именно пнуть другой процесс

В рамках хоста еще есть файлы на tmpfs.

Гуру говорят что сокеты самое Ъ, но я даже между хостами уже давно предпочитаю пайпы (cin/cout) поверх ssh, оно как то проще.

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

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

В рамках хоста еще есть файлы на tmpfs

Был бы еще способ просунуть через нее событие, а не данные…

Гуру говорят что сокеты самое Ъ, но я даже между хостами уже давно предпочитаю пайпы

Я тоже люблю минимально-простое и надежное.

да, оно, держу про запас как один из вариантов

В single-thread других-то особо и нет… Что-бы Вам не посоветовали - будет обёрткой вокруг этого (разной степени извращённости).

Ну есть же варианты: ждать сигнал, потом выгребать

Вы абсолютно точно не хотите этого делать - сигнал может Вас прервать в произвольный момент. Максимум обработчики сигнала сводятся к «взвести флажок и разбудить главный thread».

За совет – спасибо

В single-thread других-то особо и нет… Что-бы Вам не посоветовали - будет обёрткой вокруг этого (разной степени извращённости).

Ну, однопоточность – не священная корова для меня, просто не хотел плодить сущности. Будет проще через тред (а похоже – так и есть) – сделаю.

Будет проще через тред (а похоже – так и есть) – сделаю.

Well, если у Вас тысячи сокетов - тоже на каждый из них thread форкать будете? Так никто не делает.

ПыСы. Multi-thread это на голову сложнее, надо очень хорошо понимать во что Вы ввязываетесь, прежде чем.

Well, если у Вас тысячи сокетов - тоже на каждый из них thread форкать будете?

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

Так никто не делает

Ну вот я и спрашиваю :)

А чего дурного: запускаю программу, она создает тред слушатель, тот спокойно создает сокет и сидит слушает в блокировке, ресурсы не кушает. Данне пришли – выгреб и отдал колбеку в основную программу, пусть разбирается че там, а мы слушаем дальше. Напугай что может пойти не так (и обязательно пойдет), плиз.

Multi-thread это на голову сложнее, надо очень хорошо понимать во что Вы ввязываетесь, прежде чем.

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

Дык событие это изменение времени обновления файла.

Проще кмк ничего не придумать

А как на это колбек повесить? Сидети и читать раз в секунду так же в отдельном треде, а когда изменится – звать колбек? Ну такое себе (хотя бы потому что секунда тормозов)

Зачем в отдельном треде? В mainloop проверять файлы, если у кого то время поменялось и данные в нем валидны - обработать событие и запомнить новое время обновления.

Вставлять или не вставлять задержку это уже второй вопрос, я ж не знаю какие у Вас требования по латентности и т.д.:-)

И главное – надежность.

Поверьте - больше чем в single-thread её не будет. Сколько у Вас ядер на машинке? Макс 64-128. Не хотите Вы форкать threads сильно больше этого. Никогда.

А вообще клево, действительно – проще некуда и фиг сломаешь. Жалко что у меня доступа в главную петлю, как правило, нет чтоб там поллить, а так – огонь, одобряю.

Поверьте - больше чем в single-thread её не будет

Согласен.

Сколько у Вас ядер на машинке?

Джва )

Не хотите Вы форкать threads сильно больше этого.

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

Я не понял – зачем.

Потому что это тот уровень parallelism которого можно физически добиться, дальше начинаются serious shared resource contentions.

Жалко что у меня доступа в главную петлю, как правило, нет

Тогда думать надо… и слушать что говорит bugfixer, это его полянка.

Наверное надо ответить на следующие вопросы:

1. число опрашиваемых процессов и топология (каждый с каждым взаимодействует, один со всеми, направление трафика данных)?

2. характерная частота событий?

3. сколько ресурсов (времени) надо для обработки одного события?

4. какую максимальную латентность (задержку между событием и началом его обработки) надо обеспечить?

Как я понял тут вопрос как сделать проще а не как сделать шоб работало быстрее. На 15ти тредах которые в основном спят сильно не просядешь, веб-браузер сильно больше их генерит вроде бы.

Не, я не понял зачем столько сотен тредов, а не по одному треду на процесс

число опрашиваемых процессов и топология (каждый с каждым взаимодействует, один со всеми, направление трафика данных)?

10-20 штук, топология – каждый с каждым, желательно без сервера

характерная частота событий?

Максимум – десяток в секунду

сколько ресурсов (времени) надо для обработки одного события?

мало. Сообщения вида: измени такую-то свою переменную

какую максимальную латентность (задержку между событием и началом его обработки) надо обеспечить?

Не принципиально, но не секунду же :)

10-20 штук, топология – каждый с каждым, желательно без сервера

Каждый с каждым это реально разные данные двунаправленно в каждой паре ходят, или просто каждый машет ручкой остальным «всем поставить a=1», «всем поставить b=2»?

Во-первых - Антон сильно преувеличивает «мои заслуги перед отечеством». А во вторых - треды нужно форкать осмысленно. Обычно это или IO, или долгие вычисления.

Ну я планирую чтоб можно было адресно отправить сообщение: ты, поставь а=1 и чтоб широковещательно: всем ставить б=2, однонаправленно

Ну так покритикуй мою модель же!

ну так покритикуй мою модель же!

Дык, а «модель» то в чём?

ПРи запуске приложения, которое должно уметь принимать «пинки» создавать тред (один) в котором тем или иным способом слушать какой-нибудь сокет/пайп/почередь_сообщений в блокирующем режиме, при приходе сообщения – вычитывать, звать колбек основного приложения, отдавать ему данные и вновь уходить на итерацию блокирующего чтения – ждать следующего сообщения

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

И? Какого порядка latency Вы пытаетесь добиться?

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

Максимум обработчики сигнала сводятся к «взвести флажок и разбудить главный thread».

Ну почему же. Есть удобный signalfd.

Не взлетел. Я про API.

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

Подводных камней достаточно

Ну в студию же!

Порядка одной десятой секунды

Хех. Я за «микросами», и иногда и «наноми» гоняюсь…

Да я про че и говорю, уверен что то что получится – будет более чем реактивно для меня

Ну, сначала пайпы форкаются, затем их можно (и нужно) прослушивать асинхронно.

libuv.org

так там тот же поллинг + те же треды. Только там threadpool, т.е. треды создаются сразу на старте, а по отработке не умирают, а возвращаются в пул и висят на wait-е, если не нужны (из-за чего нет накладных расходов на старт/смерть тредов).

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

Не забыть про таймаут на блокировке.

все зависит от нужд и потребностей принимающей стороны.

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

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

А в течении какого времени оно должно работать без остановки?

Так то модель КМК такая должна быть:

1. каждый процесс пишет сообщения в свой файл на tmpfs, в сообщении в тч указывается адресат

2. каждый процесс следит за всеми остальными файлами, выцепляет оттуда то что относится к нему и обрабатывает. Проще всего это конечно делать в основном цикле, если это невозможно то… а почему это невозможно? Если скажем делать это в отдельном треде, то он все равно должен блокировать изменения переменных для основного цикла. То есть воткнуть в основный цикл поднятие/опускание блокировки можно, а вызов функции которая переменные перенастраивает нельзя? Второе кажется гораздо более простым…