Sharing dynamically allocated data across DLL instances?
-
I'm working on an architecture that will require a DLL to host a singleton object that will be accessible by multiple applications. It's clear that I can store the pointer to the singleton in a shared data segment, so that it will be used by all instances of the DLL... but the pointer will point to a dynamically allocated object, which itself will contain pointers to other dynamically allocated objects. Now as I understand it, these DA'd objects will be mapped into the address space of the app that first loade the DLL, correct? This means they won't be accessible to other applications, correct? If my logic is correct.. how can I share these objects between instances? Color me puzzled.
-
I'm working on an architecture that will require a DLL to host a singleton object that will be accessible by multiple applications. It's clear that I can store the pointer to the singleton in a shared data segment, so that it will be used by all instances of the DLL... but the pointer will point to a dynamically allocated object, which itself will contain pointers to other dynamically allocated objects. Now as I understand it, these DA'd objects will be mapped into the address space of the app that first loade the DLL, correct? This means they won't be accessible to other applications, correct? If my logic is correct.. how can I share these objects between instances? Color me puzzled.
You are correct they will be in their private address space. However you could pass messages with object index in them. Each process would have its own objects and you'd gain access to them via the object index/id which you would use as a hashtable key/array index/ whatever. You could also try something with a memory mapped file. All processes could map the same file and try for the same load address. Then write your objects in there. Yuck. Or worse, they don't load at the same address, so them you are down to offsets from the memory mapped file address. Double yuck. Can't think of anything for now... Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
-
You are correct they will be in their private address space. However you could pass messages with object index in them. Each process would have its own objects and you'd gain access to them via the object index/id which you would use as a hashtable key/array index/ whatever. You could also try something with a memory mapped file. All processes could map the same file and try for the same load address. Then write your objects in there. Yuck. Or worse, they don't load at the same address, so them you are down to offsets from the memory mapped file address. Double yuck. Can't think of anything for now... Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
I don't have too much experience with them, but couldn't you use an Atom if it's a string value that you're trying to store? Do Atoms work for non-string items? Jamie Nordmeyer Portland, Oregon, USA
-
I'm working on an architecture that will require a DLL to host a singleton object that will be accessible by multiple applications. It's clear that I can store the pointer to the singleton in a shared data segment, so that it will be used by all instances of the DLL... but the pointer will point to a dynamically allocated object, which itself will contain pointers to other dynamically allocated objects. Now as I understand it, these DA'd objects will be mapped into the address space of the app that first loade the DLL, correct? This means they won't be accessible to other applications, correct? If my logic is correct.. how can I share these objects between instances? Color me puzzled.
Is an NT service an option? If so, this is a good way to do what you asked. If not (and MFC is an option), look at the CMemFile class. There are samples on MSDN. If MFC and CMemFile are not an option you can still use API functions to create memory mapped files. Check out this link to the MSDN library: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/hh/winbase/dll\_9khl.asp If none of these options will work for you, you can create a second EXE which will host a named pipe or other inter-process communication layer (TCPIP listner) which can be launched to distribute the data. (This is probably overkill, though.) Thanks Matt Gullett
-
I'm working on an architecture that will require a DLL to host a singleton object that will be accessible by multiple applications. It's clear that I can store the pointer to the singleton in a shared data segment, so that it will be used by all instances of the DLL... but the pointer will point to a dynamically allocated object, which itself will contain pointers to other dynamically allocated objects. Now as I understand it, these DA'd objects will be mapped into the address space of the app that first loade the DLL, correct? This means they won't be accessible to other applications, correct? If my logic is correct.. how can I share these objects between instances? Color me puzzled.
I have extensive experience with shared memory and, to the best of my knowledge, what you are attempting is not possible. What you could do though is separate the data from the methods and declare structures that you place in a memory mapped file. You could then create objects that map to invidual instances of the data structures. I have done similar things and, while it isn't exactly clean, it is workable and not overly complex. Unfortunately, character strings must be either of fixed length or allocated from a 'pool' of characters. If the data structures are highly dynamic then the fixed length option is probably better. Best of luck.