Мне нужно сделать dll, которая бы содержала общую секцию данных для нескольких процессов. Способ создания такой секции тут (с недостатками этого способа — ознакомлен). В "общую" секцию хочу положить std:map и теоретически все вроде должно заработать, но знаний Си явно не хватает, поскольку с примерами работы с std:map разобрался, а вот что-то реальное сделать совсем не пойму как.
Постараюсь объяснить суть задачи. Нужно иметь общую память для нескольких .NET приложений (именно общую память, а не организовать обмен данными между процессами). Данные, хранящиеся в этой памяти представляют собой список пар <key, value>. Key имеет строго типизированное значение (int), а value может быть любым (object (в терминах .net)). Обрабатывать данные внутри этой dll мне не требуется, а только лишь достать value по ключу.
Как будет выглядеть описание std:map в этом случае (std:map<int, ???> &data; )
А> Постараюсь объяснить суть задачи. Нужно иметь общую память для нескольких .NET приложений ... А> Как будет выглядеть описание std:map в этом случае (std:map<int, ???> &data; )
Как связаны между собой .NET и std::map? В .NET свои контейнеры, их и используй. Причем тут std и С++ вообще?
Здравствуйте, Аноним, Вы писали:
А>В "общую" секцию хочу положить std:map и теоретически все вроде должно заработать,
Не должно это заработать. Ни теоретически ни, уж тем более практически.
Смотри почему:
1) В разных процессах шареная секция может размещаться оп совершенно разным адресам.
2) std:map по сути это дерево, узлы которого расположени на фристоре. А фристор у каждого процесса свой
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, Аноним, Вы писали:
А>>В "общую" секцию хочу положить std:map и теоретически все вроде должно заработать, DEA>Не должно это заработать. Ни теоретически ни, уж тем более практически. DEA>Смотри почему: DEA>1) В разных процессах шареная секция может размещаться оп совершенно разным адресам. DEA>2) std:map по сути это дерево, узлы которого расположени на фристоре. А фристор у каждого процесса свой
boost::interprocess (включая их собственные контейнеры) предназначен как раз для этих целей
Здравствуйте, Vamp, Вы писали:
А>> Постараюсь объяснить суть задачи. Нужно иметь общую память для нескольких .NET приложений ... А>> Как будет выглядеть описание std:map в этом случае (std:map<int, ???> &data; )
V>Как связаны между собой .NET и std::map? В .NET свои контейнеры, их и используй. Причем тут std и С++ вообще?
std и C++ для объявления секции в dll с атрибутами read, write, shared. Именно std:map... просто хранилище <key, value>. Да, действительно у .NET куча своих контейнеров (Dictionary<Key, Value>, Hashtable и т.д.), но к сожалению линкёр .NET не может определить custom секцию (по крайней мере мне не известен аналог #pragma data_seg(...)).
При этом необходимо избежать сериализации при перемещении данных между процессами. Как следствие MMF, pipe, RPC (.net remoting) и все остальные отпадают... нужна именно общая память.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, Аноним, Вы писали:
А>>В "общую" секцию хочу положить std:map и теоретически все вроде должно заработать, DEA>Не должно это заработать. Ни теоретически ни, уж тем более практически. DEA>Смотри почему: DEA>1) В разных процессах шареная секция может размещаться оп совершенно разным адресам.
Цитата из MSDN: http://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.80).aspx
Win32 DLLs are mapped into the address space of the calling process. By default, each process using a DLL has its own instance of all the DLLs global and static variables. If your DLL needs to share data with other instances of it loaded by other applications, you can use either of the following approaches:
Create named data sections using the data_seg pragma.
Use memory mapped files. See the Win32 documentation about memory mapped files.
То есть (по крайней мере в теории должно)
DEA>2) std:map по сути это дерево, узлы которого расположени на фристоре. А фристор у каждого процесса свой
Здравствуйте, dimasl, Вы писали:
D> То есть (по крайней мере в теории должно)
Ты, теоретик, дальше читай:
Each process gets its own address space. It is very important that pointers are never stored in a variable contained in a shared data segment. A pointer might be perfectly valid in one application but not in another.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, dimasl, Вы писали:
D>> То есть (по крайней мере в теории должно) DEA>Ты, теоретик, дальше читай: DEA>
DEA>Each process gets its own address space. It is very important that pointers are never stored in a variable contained in a shared data segment. A pointer might be perfectly valid in one application but not in another.
Ну... Ok. То есть, Вы утверждаете, что нет никакой возможности "расшарить" список (через память) между приложениями. Я правильно понимаю?
Здравствуйте, dimasl, Вы писали:
D> Ну... Ok. То есть, Вы утверждаете, что нет никакой возможности "расшарить" список (через память) между приложениями. Я правильно понимаю?
std::map — нет.
Специально писаный — можно. Но сложно.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, dimasl, Вы писали:
D>> Ну... Ok. То есть, Вы утверждаете, что нет никакой возможности "расшарить" список (через память) между приложениями. Я правильно понимаю? DEA>std::map — нет. DEA>Специально писаный — можно. Но сложно.
Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает.
Здравствуйте, dimasl, Вы писали:
DEA>>Специально писаный — можно. Но сложно. D> Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает.
Он врёт. Специально написаный — легко и просто.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, dimasl, Вы писали:
DEA>>>Специально писаный — можно. Но сложно. D>> Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает. C>Он врёт. Специально написаный — легко и просто.
C>http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess.html
Хм... заманчиво. Но по моему, Вы несколько не контексте обсуждения... у меня основные процессы (клиенты и сервера) .NET (точнее ASP.NET) и надо "извернуться" на разделение памяти между ними. Не будет ли boost перебором? На сколько я смог понять... придется делать некий процесс (сервер), который будет тащить эту "общую на всех" память. Я прав?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, dimasl, Вы писали:
D>> Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает.
CS>http://garret.ru/shmem/Readme.htm
Здравствуйте, dimasl, Вы писали:
D>Хм... заманчиво. Но по моему, Вы несколько не контексте обсуждения... у меня основные процессы (клиенты и сервера) .NET (точнее ASP.NET) и надо "извернуться" на разделение памяти между ними. Не будет ли boost перебором? На сколько я смог понять... придется делать некий процесс (сервер), который будет тащить эту "общую на всех" память. Я прав?
Про .NET я пропустил.
С ним ничего не получится, управляемые объекты между процессами разделять нельзя. В смысле, вообще нельзя без грязных хаков.
Здравствуйте, Cyberax, Вы писали:
DEA>>>Специально писаный — можно. Но сложно. D>> Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает. C>Он врёт. Специально написаный — легко и просто.
Емуж надо как я понял между .NET процессами расшарить данные.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
D>>> Ok. А могу ли я поинтересоваться как? Ссылки, примеры, мысли... если Вас это не очень напрягает. C>>Он врёт. Специально написаный — легко и просто. CC>Емуж надо как я понял между .NET процессами расшарить данные.
Объекты между процессами в .NET один фиг не расшарить (они же двигаются). Можно их, конечно, за-pin'ить — но это тогда ВСЁ умрёт очень быстро.
Структуры и массивы структур шарить, при желании, можно.
В любом случае про это вот твое:
"а value может быть любым (object (в терминах .net))"
придется забыть. object (в терминах .net) это GC-able сущность. Разные процессы — разные GC.
Т.е. "межпроцессном пространстве" только native (non-managed) objects.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, dimasl, Вы писали:
D>>Спасибо.
CS>Ай ничего не не нада...
CS>В любом случае про это вот твое: CS>"а value может быть любым (object (в терминах .net))" CS>придется забыть. object (в терминах .net) это GC-able сущность. Разные процессы — разные GC. CS>Т.е. "межпроцессном пространстве" только native (non-managed) objects.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Т.е. "межпроцессном пространстве" только native (non-managed) objects.
A>Вопрос в том, какова плотность и температура объектов в межпроцессном пространстве?
Имеется ввиду с какой интенсивностью будет происходить обмен? Ну сейчас это порядка 20 "перемещений" в секунду (сериализация "поедает" при этом порядка 50% CPU... эт много ) думаю в дальнейшем до 100 в секунду.
) думаю в дальнейшем до 100 в секунду.
