переход на Linux с QNX

Интересует именно расширения реального времи для Linux (раз уж с QNX), или общие? Из общих можно использовать те же локальные сокеты: процесс пишет в сокет сообщение и затем read'ом из него читает ответ, по read'у процесс будет заблокирован, до тех пор пока ответа не будет. Аналогично с каналами.

Что касается RT, то, например, в Xenomai есть описанные средства посылки сообщений между RT-задачами.

чистого SRR в *NIX к сожалению нет. впрочем, можно обойтись и другими IPC.

// wbr

Неименованые каналы, Очереди сообщений POSIX/System V? Не?

epoll?

Это не прокатит. Организовать межпроцессный обмен на udp сокетах можно. Посадить процессы в select, к примеру - да, он будет заблокирован на чтение. Но проблема в том, что из select его вышибет любой другой процесс, сделавший sendto - а нужна именно блокировка до тех пор, пока не ответит вызываемый процесс. Про каналы тоже думал. Но на примерно 20 процессов организовывать каналы "каждый с каждым" ресурсов не хватит. И потом канал не решает основной задачи - блокировка вызывающего, до ответа вызываемого. Повторюсь, важна не реалтаймовость, а обеспечение асинхронной работы.

> epoll?

спасибо

Не :) неименованные каналы в принципе не пойдут, дочерние процессы не форкаются, они самостоятельны. Но не пойдут даже каналы именованные - они обеспечивают атомарность сообщения и их очередность, да. Кстати, поправьте, если ошибаюсь - в нынешних реализациях POSIX каналы основаны на очередях сообщений, нет? Так вот, очередь тоже не решит искомой задачи - она обеспечивает блокирование читающего процесса до извлечения очередного следующего сообщения, неважно кто его в эту очередь поместил. А нужно - блокирование на чтение _пока_не_ответит_конкретный_процесс. Остальные процессы системы при этом живут своей жизнью, и да, отправляют сообщения блокированному в том числе.

Вот тут посмотрите http://www.cogent.ca/index.html?http://www.cogent.ca/Software/SRR.html

http://developers.cogentrts.com/srr/README.html

UNIX domain sockets + epoll?

SunRPC

> SunRPC

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

// wbr

> самое похожее, что приходит в голову - это UDP.

точнее, гарантированный UDP.

// wbr

>> SunRPC

> даже близко не лежало.

"А нужно - блокирование на чтение _пока_не_ответит_конкретный_процесс". И чем SRR не RPC?

> самое похожее, что приходит в голову - это UDP.

Протокол другого уровня.

ну епть - че изобретать-то, уже изобрели см по ссылкам выше "Cogent SRR Module Synchronous message passing for Linux The SRR Module is an open-source project maintained by Cogent, and distributed under the a GNU General Public License (GPL). It provides synchronous message passing, asynchronous event notification (proxies), and user-space interrupt handling for the Linux operating system. Synchronous message passing is a fast, flexible, and robust IPC mechanism, particularly useful for building systems composed of multiple co-operating processes. ... The SRR Module is very stable and extremely fast, at approximately 80% of QNX 4's performance on the same hardware. "

> ну епть - че изобретать-то, уже изобрели

Я не предлагал ничего изобретать.

Кстати, вот это: http://www.icanprogram.com/simpl/ вроде даже по API совместимо с QNX.

> точнее, гарантированный UDP.

а оно где-нить реализовано? А то скока не смотрю проги, везде общение идёт на уровне сообщений а не на уровне потоков. Вот и приходится сообщения по кускам собирать, отделять друг от друга итп. Бесит жутко. Короче, хочу чтобы транзакциями ходили сообщения :(. sctp как-то совсем не растпространён, до недавнего времени в нём куча багов была в линухе(conntrack там глючил итп), да и держат ли его провайдеры? А rudp кто-нить юзает?