Статья :
IPC: основы межпроцессного взаимодействия

Автор(ы): Алекс Jenter
Дата: 10.03.2001
Обзор основных технологий IPC: Очень многим приложениям, если не большей части, требуется
информация от других приложений, либо они должны эту информацию сообщать.
Именно поэтому в операционную систему встраивается множество механизмов,
которые обеспечивают т.н. Interproccess Communication (IPC) — то есть
межпроцессное взаимодействие...

Авторы :
Алекс Jenter

Аннотация :
Обзор основных технологий IPC: Очень многим приложениям, если не большей части, требуется информация от других приложений, либо они должны эту информацию сообщать. Именно поэтому в операционную систему встраивается множество механизмов, которые обеспечивают т.н. Interproccess Communication (IPC) — то есть межпроцессное взаимодействие...

Как я понимаю нет проблем с организацией данной вещи в ДЛЛ. Вопрос в том можно ли это организовать без дополнительного thread. Если да, то как это будет выглядеть? (в общих чертах)

Интересно: что это за способ объявления переменной в DLL, которая доступна из других процессов подключивших DLL? Очень интересно. Сразу напрашивается вопрос — а как, по-вашему, происходит процесс mapping'а?

P.S.
Все здесь конечно красиво (под IE), но вот с Opera проблемы.

Это очень просто. Переменная объявляется в отдельном сегменте, которому присваивается отрибут RWS

#pragma data_seg("Shared")
long g_var;
#pragma data_seg()
#pragma comment(linker,"/SECTION:Shared,RWS")

У Рихтера всё подробно расписпно... А мапинг происходит как обычно.

З,Ы,
Мда, мне под Оперой это всё тоже жутко не нравится :(

Расшареные секции данных — это прекрасно. Есть однако НО, Microsoft сами утверждают что поддержка этой схемы не гарантирована. Есть вариант независимый от компилятора. Основан на memory mapped file. Смотреть http://codeguru.earthweb.com/samples/pwdspy.html
В качестве дополнительного плюса идёт то, что нет ограничений по типу данных.

Если для некоторой секции не выставлены одновременно флаги IMAGE_SCN_MEM_EXECUTE и IMAGE_SCN_MEM_WRITE, но выставлен IMAGE_SCN_MEM_SHARED, то Copy-on-Write не включается. Следовательно, процессы, подключившие dll, имхо (не проверял) реально могут иметь общий доступ к содержимому этой секции.

Slicer

Здравствуйте, Алекс Jenter, Вы писали:

Если автор статьи невозражает то хотелось бы внести маленькое предложение на дополнение данного пункта статьи, мне кажется оно существенное:

АJ>Почтовые слоты (mailslots)
АJ>Почтовые слоты — это механизм однонаправленного IPC. Если приложению известно имя слота, оно может помещать туда сообщения, а приложение-хозяин этого АJ>слота (приемник) может их оттуда извлекать и соответствующим образом обрабатывать. Основное преимущество этого способа — возможность передавать сообщения АJ>по локальной сети сразу нескольким компьютерам за одну операцию. Для этого приложения-приемники создают почтовые слоты с одним и тем же именем. Когда в АJ>дальнейшем какое-либо приложение помещает сообщение в этот слот, приложения-приемники получают его одновременно.

Наверное стоит указать, что механизм mailslots на траспортном уровне использует дейтаграммы для передачи пакетов, что в свою очередь НЕ ГАРАНТИРУЕТ доставку этого самого пакета клиенту.

Здравствуйте, Microsoft, Вы писали:

M>Это очень просто. Переменная объявляется в отдельном сегменте, которому присваивается отрибут RWS

M>#pragma data_seg("Shared")
M>long g_var;
M>#pragma data_seg()
M>#pragma comment(linker,"/SECTION:Shared,RWS")

Здесь маааааааленькая ошибка:
переменная g_var не инициализирована поэтому автоматом попадет в секцию с неинициализированными данными, и не будет shared.

M>Наверное стоит указать, что механизм mailslots на траспортном уровне использует дейтаграммы для передачи пакетов, что в свою очередь НЕ ГАРАНТИРУЕТ доставку этого самого пакета клиенту.

А какой протокол гарантирует?

Здравствуйте, Tom, Вы писали:
Tom>А какой протокол гарантирует?

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

Slicer

Здравствуйте, Tom, Вы писали:

M>>Наверное стоит указать, что механизм mailslots на траспортном уровне использует дейтаграммы для передачи пакетов, что в свою очередь НЕ ГАРАНТИРУЕТ доставку этого самого пакета клиенту.

Tom>А какой протокол гарантирует?

На сколько я помню только mailslots из IPC не гарантирует, т.к. дейтаграммы могут потерятся где нибудь , плюс у них есть определенный срок жизни. Все остальные механизмы вроде гарантируют. Лично использовал named message pipes — все вроде ОК никаких неожиданных артефактов не обнаружилось. Правдо как то на RSDN разгорался спор (совсем недавно) по поводу WM — является ли этот механизм гарантированным средством доставки сообщений или нет!

Удачи!

SM>Например, файл-маппинг... Он гарантирует, что данные будут доступны для клиента, ему их останется только открыть и прочитать, но есть гарантия, что никуда они не денутся. Дейтаграммы же обычно имеют срок жизни (правда, как обстоит дело в данном случае — не знаю), и, кроме того, могут просто где-то заблудиться — в общем, доступность данных клиенту не гарантируется.

А что файл-маппинг это уже протокол?
Мы же о протоколах веджём речь...