Is it possible to have one Server App using Boost’s managed_windows_shared_memory to create a memory segment and an object (an integer or a string, for example), and another Client that uses the native Windows API (i.e. the Memory-Mapped Files) to access said memory segment and object?
The reason why the Client has to use pure native Windows API instead of Boost is because (as our testing shows) the Client will hang due to some permission and spin_lock issues after it uses ::find to obtain the pointer to the object in the shared memory. We’re not sure why it turns out like this, but we suspected it has something to do with the Client using another version of Boost. The Client is itself a plugin for another propriety software (which use Boost 1.4x, while we use 1.55), so recompiling everything (the Client AND the propriety software) with our own version of Boost isn’t an option.
On the other hand, when the Client sticks with the native Windows API, and the Server uses Boost’s windows_shared_memory along with map_region, we can at least have them share a serialized char string.
So the next question we have is whether we can have the Server use a managed_windows_shared_memory instead. If we have the shared object created as a name object by the Server, is it possible for the Client to access this shared object? What else do we need to accomplish this?
If this is remotely possible, I suspected that the Server will need to obtain some info on the shared object’s address, and send it to the Client (through message queue or sockets). The Client can then access the shared object using this information. Is that a plausible path to work towards?
I’ve just started using Boost’s IPC, though, so maybe there are other ways to do this. Thanks in advance for any suggestions or examples on how this can be done; I would truly appreciate it.
Ingrid
