Информация об изменениях

Сообщение Re[3]: Мультипроцессный защищенный код от 01.04.2018 13:33

Изменено 01.04.2018 13:54 Pavel Dvorkin

Re[3]: Мультипроцессный защищенный код
Здравствуйте, Barbar1an, Вы писали:

B>ну вообще я вкурсе как расшарить кусок данных, это не проблема


B>я же хочу расшарить статические объекты



Можно, и ты сам пишешь, что в курсе

>и кучу


А вот это AFAIK нет.

>чтобы я мог обращаться к расшареным объектам как к обычному объекту, но с тем пониманием что он существует в одном экземпляре среди всех моих процессов


file mapping, shared section в DLL.

B>при этом чтобы когда я писал код главного процесса, я мог написать


B>auto d = new CObject ...


Только если переопределить operator new так, чтобы он выделял память в расшаренной области.

B>и этот указатель становился сразу доступным всем дочерним процессам без спецаильных мер


https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa366763(v=vs.85).aspx

Если все процессы укажут один и тот же желаемый адрес, и все эти запросы будут удовлетворены, то адрес будет один и тот же у всех процессов. Но нет никакой гарантии, что запросы всех процессов будут удовлетворены — в каком-то из процессов этот адрес может быть банально чем-то занят

B>но при этом дочерние процессы не должны иметь возможности покоцать эти общедоступные объекты


Это не проблема, пусть только главный создает мэппинг R/W, а дочерние R/O

B>типа сделать глобальный пул, в нём порождать всё не перебирая, что нужно а что нет — это удобство

B>этот пул замапить во все дочерние процесс как read-only

Да, примерно так и будет

B>тогда можно было бы дергать в дочерних процессах указатели на данные в этом пуле напрямую, и не бояться похерить их


Можно

B>но это реально тока если адреса маппинга страниц памяти во всех процессах будут одинаковые — можно ли такое? иначе ничего не получится, потому что указатели же ж это абсолютные значения в виртуальном пространстве адресов


См. выше.
Re[3]: Мультипроцессный защищенный код
Здравствуйте, Barbar1an, Вы писали:

B>ну вообще я вкурсе как расшарить кусок данных, это не проблема


B>я же хочу расшарить статические объекты



Можно, и ты сам пишешь, что в курсе

>и кучу


А вот это AFAIK нет.

>чтобы я мог обращаться к расшареным объектам как к обычному объекту, но с тем пониманием что он существует в одном экземпляре среди всех моих процессов


file mapping, shared section в DLL.

B>при этом чтобы когда я писал код главного процесса, я мог написать


B>auto d = new CObject ...


Только если переопределить operator new так, чтобы он выделял память в расшаренной области.

B>и этот указатель становился сразу доступным всем дочерним процессам без спецаильных мер


https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa366763(v=vs.85).aspx

Если все процессы укажут один и тот же желаемый адрес, и все эти запросы будут удовлетворены, то адрес будет один и тот же у всех процессов. Но нет никакой гарантии, что запросы всех процессов будут удовлетворены — в каком-то из процессов этот адрес может быть банально чем-то занят

Но вообще-то особой необходимости иметь эти адреса одинаковыми для всех процессов нет. Пусть каждый процесс маппит независимо, и базовые адреса будут различными. Если после этого каждый процесс будет оперировать не абсолютным адресом, а смещением от базового адреса, то все будет в порядке

Кстати, в VC++ есть вот такое

https://msdn.microsoft.com/en-us/library/57a97k4e.aspx

B>но при этом дочерние процессы не должны иметь возможности покоцать эти общедоступные объекты


Это не проблема, пусть только главный создает мэппинг R/W, а дочерние R/O

B>типа сделать глобальный пул, в нём порождать всё не перебирая, что нужно а что нет — это удобство

B>этот пул замапить во все дочерние процесс как read-only

Да, примерно так и будет

B>тогда можно было бы дергать в дочерних процессах указатели на данные в этом пуле напрямую, и не бояться похерить их


Можно

B>но это реально тока если адреса маппинга страниц памяти во всех процессах будут одинаковые — можно ли такое? иначе ничего не получится, потому что указатели же ж это абсолютные значения в виртуальном пространстве адресов


См. выше.