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

O>У вас некоторая каша в голове. Но ответ — реально. Код клиента — это процесс клиента, код сервиса — это процесс сервиса.
O>То что вы хотите реализовывается по тому же сценарию что я описал в первой мессаге, с некоторыми дополнениями
O>1) Сервис мапит файлампинг клиенту с PageProtection = PAGE_READONLY.
O>2) Синхронизация все равно потребуется, но без подвыподвертов, связанных с безопасностью. Кстати, чтобы достить максимума производительности можно сделать аналог критической секции на расшаренной памяти, что означает что помимо READ/WRITE области памяти потребуется еще одна маленькая область, writable для клиента, чтобы тот мог реализовать на ней. Обычную CRITICAL_SECTION так заюзать нельзя. Будет ли буст оптимален для такого сценария или у них межпроцессная синхронизация тупо на CreateMutex/WaitForSingleObject сделана — я хз. Когдато очень давно я писал свой велосипед с такой целью, но он проприетарен.

вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.
сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора

все клиенты будут загружать сервисную длл

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

т.е. сервисная длл тут выступает как прокси, который ограничивает клиентов в праве на запись в общий хип

т.е. чтобы в итоге код сервисной длл мог возвращать указатели на с++ объекты в общем хипе
а клиенты могли читать эти указатели и делать вызовы этого кода, но не могли сами писать в общий хип

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

O>У вас некоторая каша в голове. Но ответ — реально. Код клиента — это процесс клиента, код сервиса — это процесс сервиса.
O>То что вы хотите реализовывается по тому же сценарию что я описал в первой мессаге, с некоторыми дополнениями
O>1) Сервис мапит файлампинг клиенту с PageProtection = PAGE_READONLY.
O>2) Синхронизация все равно потребуется, но без подвыподвертов, связанных с безопасностью. Кстати, чтобы достить максимума производительности можно сделать аналог критической секции на расшаренной памяти, что означает что помимо READ/WRITE области памяти потребуется еще одна маленькая область, writable для клиента, чтобы тот мог реализовать на ней. Обычную CRITICAL_SECTION так заюзать нельзя. Будет ли буст оптимален для такого сценария или у них межпроцессная синхронизация тупо на CreateMutex/WaitForSingleObject сделана — я хз. Когдато очень давно я писал свой велосипед с такой целью, но он проприетарен.

вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.
сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора

все клиенты будут загружать сервисную длл

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

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

т.е. чтобы в итоге код сервисной длл мог возвращать указатели на с++ объекты в общем хипе
а клиенты могли читать эти указатели и делать вызовы этого кода, но не могли сами писать в общий хип