LINUX.ORG.RU
Форум — Development  

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


0

0

Общественность, подскажите, кто сталкивался, в каком направлении рыть. В QNX есть чудесный механизм send-reply, когда процесс, отправивший другому send, встает в блокированное состояние и практически не ест системных ресурсов, пока вызываемый процесс не ответит ему reply. Теперь встала задача перевести проект под linux. Есть ли какой-то аналог такого типа IPC в linux? Стандартные семафоры не предлагать, в системе порядка 20 взаимодействующих друг с другом процессов с разными приоритетами. Интересует не собственно механизм отправки сообщения другому процессу, тут проблем нет, а именно блокирование процесса-инициатора до получения ответа. В частности, важно, что бы блокированный процесс не принимал send'ы от других процесов, а они бы накапливались в очереди.

anonymous

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

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

Begemoth ★★★★★
()


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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от Begemoth

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

anonymous
()
Ответ на: комментарий от one_more_hokum

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

anonymous
()
Ответ на: комментарий от tailgunner

> SunRPC

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>> SunRPC

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

ну епть - че изобретать-то, уже изобрели см по ссылкам выше "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. "

anonymous
()
Ответ на: комментарий от klalafuda

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

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

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development