Ion Gazta?aga wrote
Mike Spertus escribi?:
I'm being bitten by the surprise discovery that different Windows users can't(?) communicate via named shared memory using Boost Interprocess as in the post below from 2008-09-18 (Changing all processes to use the same TMP directory is not an option for us due to interoperability requirements). Is there a workaround? Was anything ever done about the proposed solution below? Another alternative would be to make it possible to specify the "Boost Interprocess temp directory".
For boost 1.40 I've changed the TMP directory for the Common Documents directory, searching that folder using the registry. In theory, that folder is accessible by all processes and should be present in all systems. Nevertheless, I'll add the option to specify the temp directory to my to-do list, maybe using an environment variable?
Best,
Ion
Hi Ion, Thanks for the response. boost 1.40 will be a big help. Among other things, I have found that this results in a much more serious problem, which is that boost interprocess named mutexes do not provide mutual exclusion because the service and application will use different directories to hold the shared memory mappings that back the mutex. As far as specifying the temp directory, providing an API instead of an envar would prevent conflict with other apps using boost::interprocess if we distribute our application and have to set a global envar in our installer. Thanks again, Mike