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

O>Но это все равно глупая затея. И дело не в трудоемкости. Защищенность сервиса предполагает, что клиент не сможет его порушить. А значит, что сервису придется тщательно смотреть за структурами данных, которые ему в расшаренную память положил процесс. Причем это значит, что клиент, будучи написанным хакером, может abuse-ить ваш протокол, к примеру записывая в расшаренную память в обход предусмотренного механизма синхронизации. Это не то чтобы нерешаемая задача — можно обеспечить транзакционную синхронизацию, переключающую режим работы хипа между клиентом и сервисов устанавливая защиту на страницы памяти которую клиент не сможет изменить, но по итогу с такой синхронизацией + проверками валидности данных работать оно врядл будет быстрее чем реализация протокола-через-пайпы. А без них — ни о какой защищенности кода говорить нельзя и проще заюзать предложенный выше буст.


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

тогда нужно будет лишь хорошо проверять входные параметры и всё