IPC Qt/C#/C++, Межпроцессное взаимодействие Опции

[JustOneQuestion]

Спасибо, Iron Bug за наводки. Но если я правильно понимаю, то это скорее примеры способов передачи данных. Подробно не разбирался, но что именные каналы что ACE работают с данными по принципу пишем-читаем. Если есть что прочитать - прочитаем.Захотели записать- запишем. Однако, как читателю узнать что пришли новые данные? Надо вроде постоянно самому проверять... или всё же нет и можно как-то подписаться на событие прихода данных. Меня интересует именно способ сообщить в другое преложение что что-то произошло. Это мне кажется вопрос который имеет отношение не столько к библиотекам и языку на котором пишеться сколько к возможностям ОС или железа. Например можно засунуть в обработчик прерываний микрокотроллера или микропроцессора ссылку на место в одном процессе, а вызывать будет другой процесс.(в случае микроконтроллера прерывание будет кто-то извне делать, как я описывал в первом посте.) Но в принципе ни что не мешает ... если железо позволяет ... и самому себе прерывание устроить, например ногуВввода для сигнала прерывания соеденить с ногой вывода. Это можно и совтовым способ сделать... если у железа есть под это регистры для управления такими перемычками. Если без железа это всё смотреть, то ОС должна эмулировать примерно тот же процесс с помощью своего великого и всемогущего (а так же непонятно как работающего) Планировщика_Задач. Перестаёт давать время на выполнение операций одного процесса, до тех пор, пока другой процесс не отправит сигнал планировщику о том чтобы тот разбудил первого. Тут дело вобщем-то не в библиотеках а в принципе, и мнме кажется он должен быть универсальным для всех систем... так или иначе. Исходя из этого, мне становится непонятно, почему же тогда CreateEventEx платформенно зависима? Принцип то должен быть универсальным... А вот реализация да.. может быть и разной.. Но ничто не мешает в библиотеке с CreateEventEx сделать дефайны при компиляции под определенную систему..Главное ж чтобы тот кто пишет код используя эти функции всегда одним способом мог пользоваться...Что под одну ОС что под другую. А как оно там реализовано это уже его не должно беспокоить, как не беспокоят его ("обычно") вопросы как тот или иной драйвер работает. Есть стандарт для каждого типа устройств, и работают уже с ним. А чтобы этот стандарт был един для всех физически разны устройств это уже забота драйвера.
Я что-то не то говорю?

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

[ViGOur]

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

Дело в том, что событийная модель построенна на классах, производных от QObject и с определенными макросами (Q_OBJECT), из этого класса Qt генерирует moc файлы, которые участвуют в проекте и реализуют механизм сигнал/слот.
С функциями такое не прокатит.

[Iron Bug]

Спасибо, Iron Bug за наводки. Но если я правильно понимаю, то это скорее примеры способов передачи данных. Подробно не разбирался, но что именные каналы что ACE работают с данными по принципу пишем-читаем. Если есть что прочитать - прочитаем.Захотели записать- запишем. Однако, как читателю узнать что пришли новые данные? Надо вроде постоянно самому проверять... или всё же нет и можно как-то подписаться на событие прихода данных. Меня интересует именно способ сообщить в другое преложение что что-то произошло. Это мне кажется вопрос который имеет отношение не столько к библиотекам и языку на котором пишеться сколько к возможностям ОС или железа.

в любой OS есть объекты синхронизации, которые поддерживаются ядром. собственно, процесс может опросить состояние объекта без блокирования, либо подписаться на изменение его состояния и спать, пока система его не разбудит. подобные операции реализованы везде и процесс может либо проверить наличие данных и сразу вернуть себе управление, либо спать до прихода некоторого события. когда процесс получил данные, он может делать с ними что угодно, в том числе дёргать какие-то колбэки. все реализации так или иначе делают именно это, просто эта работа выполняется библиотеками и может быть скрыта от конечного юзера. само собой ничего не делается. с разной степенью тормозов это реализовано в Qt и boost::interprocess. вопрос лишь в том, каковы требования по скорости и по поддерживаемым платформам. если реализация устраивает, то нет смысла городить свои велосипеды, в крупных кроссплатформенных библиотеках всё это есть.