Всем доброго времени суток)
Подскажите какие есть возможные варианты выделения памяти для использования ее двумя разными процессами...
Пробовал через mapping file, но там возникает проблема с указателями
Например есть 2 структуры
typedef struct _struct2 {
int * b1; // указывает на a1int b2;
} struct2;
typedef struct _struct1 {
int a1;
bb a2;
} struct1;
struct1 *qwerty; // указатель на mapping файл
При считывание получается, что a1, a2 и b2 — верные значения, а вот b1 указывает уже далеко не на a1...
Как вариант мне посоветовали extern "C"__declspec(dllexport), сказав что из .exe тоже можно экспортировать, но у меня что-то так и не получилось... хотя если создать общую dll для обоих процессов, тогда нормально получаю указатель на нужную структуру обоими процессами.
ZM>Пробовал через mapping file, но там возникает проблема с указателями
Да, конечно. Маппируются-то они в разные адреса в разных процессов. Надо вместо указателей использовать смещения от базового адреса. Они всегда валидны.
Можно, правда, попытаться их смаппировать по одному и тому же адресу в обоих процессах, используя MapViewOfFileEx
ZM>Как вариант мне посоветовали extern "C"__declspec(dllexport), сказав что из .exe тоже можно экспортировать, но у меня что-то так и не получилось... хотя если создать общую dll для обоих процессов, тогда нормально получаю указатель на нужную структуру обоими процессами.
Именно с DLL и проще всего. См. #pragma dataseg. Если использовать именованную разделяемую секцию, то она будет одной и той же для всех проекций этой DLL во все процессы.
Здравствуйте, ZestMan, Вы писали:
ZM>Всем доброго времени суток) ZM>Подскажите какие есть возможные варианты выделения памяти для использования ее двумя разными процессами...
COM. Например SxS (side-by-side) COM с такими объектами как SafeArray.
PD>Именно с DLL и проще всего. См. #pragma dataseg. Если использовать именованную разделяемую секцию, то она будет одной и той же для всех проекций этой DLL во все процессы.
dll тоже может по разным адресам грузиться. И решение на шаред секция в PE файле — потенциальная секурити дырка и источник возможных неожиданных проблем при одновременном запуске проги в разных сессиях.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ZestMan, Вы писали:
ZM>Всем доброго времени суток) ZM>Подскажите какие есть возможные варианты выделения памяти для использования ее двумя разными процессами...
в linux/unix использовать IPC SHM, хотя, внутрянке оно вроде так же через mmap реализовано.
Здравствуйте, ononim, Вы писали:
PD>>Именно с DLL и проще всего. См. #pragma dataseg. Если использовать именованную разделяемую секцию, то она будет одной и той же для всех проекций этой DLL во все процессы. O>dll тоже может по разным адресам грузиться. И решение на шаред секция в PE файле — потенциальная секурити дырка и источник возможных неожиданных проблем при одновременном запуске проги в разных сессиях.
Может, конечно. И там тоже вместо указателей надо использовать смещения.
Насчет секьюрити — сама идея разделяемых данных есть некая угроза ей. Но если автор именно разделяемые данные хочет... Если его устроили бы копии данных в каждом процессе — был бы иной разговор.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Насчет секьюрити — сама идея разделяемых данных есть некая угроза ей. Но если автор именно разделяемые данные хочет... Если его устроили бы копии данных в каждом процессе — был бы иной разговор.
Нет, копии в данной ситуации не приемлемы, необходима именно раделяемая память. Да и безопасность данной программы не столь критична в этом плане.
Здравствуйте, ZestMan, Вы писали:
ZM>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Насчет секьюрити — сама идея разделяемых данных есть некая угроза ей. Но если автор именно разделяемые данные хочет... Если его устроили бы копии данных в каждом процессе — был бы иной разговор.
ZM>Нет, копии в данной ситуации не приемлемы, необходима именно раделяемая память. Да и безопасность данной программы не столь критична в этом плане.
One use for pointers based on pointers is for persistent identifiers that contain pointers. A linked list that consists of pointers based on a pointer can be saved to disk, then reloaded to another place in memory, with the pointers remaining valid
Правда, за это приходится платить. sizeof такого указателя 8 байт, а не 4, так как он содержит базу. Я их не люблю — зачем мне хранить базу в N указателях, если для mmf она всегда одна и та же ? Но в других случаях может быть полезно.
PD>Насчет секьюрити — сама идея разделяемых данных есть некая угроза ей. Но если автор именно разделяемые данные хочет... Если его устроили бы копии данных в каждом процессе — был бы иной разговор.
Доступ к шаред секции в отображении имажа файла может по умолчанию получить любой юзер, который имеет доступ к файлу на исполнение. И это изменить низзя.
Доступ к именованному файлмэппингу по умолчанию имеют тока тот юзер, что его создал + члены группы администраторов. Это можно изменить.
Разница в этом самом "по умолчанию" — по дефолту именованные объекты в винде не позволяет пересечь trust barrier в сторону повышения привилегий без согласния на то процесса с более высокими привилегиями, а шаред секции в исполняемых модулях плевать хотели на этот барьер.
Как много веселых ребят, и все делают велосипед...
Сегодня конечно вряд ли стоит писать свой, скорее всего boost::interprocess::offset_ptr можно использовать отдельно от всего остального в Boost.Interprocess, хотя если писать приложение с самого начала я бы попробовал заиспользовать Boost.Interprocess как можно больше.
