Свой объект для epoll

создай событие (fdevent) и повешай на епол

Создать pipe, писать туда по одному байту, а на другой стороне читать?

Хорошая штука, но не понял как ее заставить работать в разных приложениях.

Разные приложения

разные приложения уже через пайп не общаются?

Хорошая штука, но не понял как ее заставить работать в разных приложениях.

Нужно передать дескриптор события из одного процесса в другой через AF_UNIX, читай например

http://poincare.matf.bg.ac.rs/~ivana/courses/ps/sistemi_knjige/pomocno/apue/A...

Или именованные пайпы

Спасибо! Замысловато.

Нужно передать дескриптор события из одного процесса в другой через AF_UNIX

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

можно, но есть недостатки:

1) нельзя передать по сокету «событие», нужно передать хотя бы байт информации, но передача данных через сокет несколько дороже eventfd

2) сокет может использоваться для передачи разных типов сообщений, т.е. входящие данные надо обраюатывать, тогда как eventfd можно передать несколько для всех важных типов событий, и обрабатывать каждый по-отдельности

3) если в схеме участвует больше двух процессов, дескриптор можно передать по цепочке

А положить его в разделяемую память нельзя? С како-то обвязкой, конечно. Вообще, похоже, что надо курить реализацию posix queue. там что-то очень похожее на, то что мне нужно.

А положить его в разделяемую память нельзя?

Нет, так как интовое значение дескриптора в разных процессах будет разным

Это да. Я имел в виду, его самого и еще какую-нибудь дополнительную информацию.

1) нельзя передать по сокету «событие», нужно передать хотя бы байт информации, но передача данных через сокет несколько дороже eventfd

Можно, но не стоит. «Чисто под события» лучше всего сигналы.

«Чисто под события» лучше всего сигналы.

По-моему, сигналы намного хуже

1) обработчик сигнала срабатывает асинхронно и в нем много чего нельзя делать. eventfd (или пайп/сокет) интегрируется в существующий event loop

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

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

Хотя теперь есть signalfd, что сглаживает п.1

1. Сигналы наиболее дешовы

2. Если сильно хочется сигналы можно перенаправить в event-loop

3. Если сильно хочется к сигналам можно подвязывать данные. На тему - USR1/USR2 - это правда только в контексте очччень старых систем.

4. Нууу ... как мед так и ложкой ...

Сигнал плох тем, что мастер должен их рассылать. Т.е. должна вестись структура подписок итд..

сигналы имели ещё некоторые неприятные особенности: https://ldpreload.com/blog/signalfd-is-useless?reposted-on-request

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