Проблем с shared DLL

Дайте смислена идея как да се преодолее следния проблем:

Имаме DLL (A) който създава обекти на C++ с оператора new, нека за простота да ги мислим за отворени файлове с буфери.

Имаме втори DLL (B), който единствен комуникира с A и събира създадените обекти (указателите им) в кеш. Идеята е който се обърне към B за обект, B го търси в кеша, и ако там го няма, вика A да го създаде. За да може кеша да е глобален, е направен в shared-segment на DLL-а.

Имаме приложение, което се обръща към B и всичко си цъка като часовник.

Проблема настава, когато ДРУГО приложение се обърне към B и в кеша има обекти, създадени при обръщение на първото приложение. Тези обекти са в адресното пространство на първото приложение (защото B и A работят в същия процес в момента на създаването). И това адресно пространство разбира се е различно за второто приложение. Така че второто приложение загива безславно.

Или накратко: един DLL, кеширащ обекти за няколко различни приложения, работещи едновременно.

Помощ!

Mi sha ti se naloji da nablqgash na memory mapped files.

Това което правя е напълно еквивалентно с това което ти предлагаш.
Проблема мисля е че алокирането на нови обекти (с new) не може да се реализира с memory-mapped механизъм. Един указател, който е валиден за един процес, не е валиден в другия. А нещата трябва да са истински C++-обекти.

Но как да се заобиколи?

Ми след създаването на обекта го копирай в мапнатия буфер, кво толкова. Не виждам какво пречи.
Другото решение е DCOM и подобни.

Я вышел им наперерез!

mi mnogo qsno, 4e nqma da stane s new... wiv pogledni GlobalAlloc(...) ;)

kjfskdhg dfs lasdjfol ldksf iwoertoret !!!

'mi predefiniraj new-to da ba4ka s shared pamet

...i posle s placement new za da si construira obekta w zadelenata pamet (shtoto iawno na obekti dyrji :) )

Е, чак да го предефинира, няма нужда. Просто може да ползва placement new-то от STL например (намира се в хедъра <new>).

Нищо не може да се направи с предефиниране на new или копиране на обекта. Защо? Защото в един обект освен данни има и указатели, най-важния от които е указателя към виртуалната таблица (където също има указатели). Тези указатели са създадени в контекста на първото приложение, и са невалидни в контекста на второто. И не могат да се преадресират към заделеното share-memory. Затова и file-mapping не работи в случая.

Проблема е тъп, но засега не виждам просто решение...

DCOM е простото решение по принцип.

Я вышел им наперерез!

Не съм запознат с него в подробности и не мога да преценя дали няма да има същите проблеми.

При този модел DLL-а има ли свой собствен контекст на изпълнение? Ако да, всичко ще е ок май.

Няма смисъл да си пишеш свой вариант на COM библиотеката след като вече я има направена. На практика си описал точно функционалността на локалните COM сървъри и маршалването на обекти между процеси.

Zdravej,
prochetoh povecheto nesta koito sa ti pisali.
Eto i moeto skromno mnenie.

1. Iavno e, che ste smeniash arhitekturata (share na poiteri m/u procesi ne e prosta rabota osobeno kato imash kod i danni)

2. Viz dali naistin ima nuzda da sharevash celi obecti i kolko chesto i kolko kato broika sa tezi obecti. nai lesno e da se ogranichish do share na danni.

3 povecheto systemi rabotiat kato client server - client prashta na servera zaiavka servera ia otrabotva i vrusta resultat i s tova vsichko svyrshva. State se pazi na clienta. Takyv design preporychvat za golemi nesta.

4. Ako iskash da pazish server 'state' m/u zaiavkite stava po slozno.
Moze na vseki tvoi obekt da mu slozish ATL shapka i da gi napyhash v MTS.
I vseki da se obryshta kym Shared memory ili Registry ili baza danni. Tova sa 3-te nachina dokolkoto znam.

5. Ne zabraviaj che kakvoto i da shervash m/u processi ste triabva da se opraviash sys sinchnozacia, semafori, locks i drugi ot sorta. Az polzvam SQL server tam vsichki tia nesta sa napraveni. Web serverite systo se spraviat.

Nadiavam se da sym ti bil polezen.
M.

Право казва Resurrector. Използвай COM.

Май ще трябва да седна да обмисля още веднъж нещата и да поекспериментирам.

Хич не ми се правеше с COM!

И аз като теб не харесвам COM, но в случая май до него опира.

Има и алтернатива, но не е по-проста. За да прехвърляш обекти в друго адресно пространство, трябва да имаш нещо като сериализация. Оттам нататък е просто - сериализираш обекта в общата памет, и после в другия процес го десериализираш.

Хубава сериализация обаче не се прави за две минути :) Решения като това на MFC не ми харесват, понеже: 1) използват собствено RTTI; 2) изискват сериализируемите класове да са наследници на CObject; 3) изискват модифициране на самия клас, т.е. можеш да сериализираш само класове, чиито сорс е изцяло под твой контрол.

Има една алтернатива без тези недостатъци, ако искаш и хвърли едно око. URL-то е [линк] . Въпросната библиотека кандидатства за приемане в Boost, но не беше приета. Все пак е много добра.

И всеки път като решиш да sharevash данни, ще даваш $10 000 за SQL Server?

Що не си пишеш бози на базик и не се бъркаш където не ти е работата :-)

j