Control of the file location for the boost::interprocess::managed_shared_memory object
Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory? The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs to interface to the database that the service created. Everything seems to work fine, but the service will open the shared memory backing file in the global temp directory while the user account will open the file in their local settings temporary directory. Therefore two different segments are opened. The interim solution is to use boost::interprocess::managed_windows_shared_memory to create the shared memory, but the desire is to use the generic version for cross-platform compatibility. If the full file path could be specified when creating the memory segment, it would solve the problem. Michael Watkins _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sy...
Michael Watkins escribió:
Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory?
No, sorry.
The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs to interface to the database that the service created.
Everything seems to work fine, but the service will open the shared memory backing file in the global temp directory while the user account will open the file in their local settings temporary directory. Therefore two different segments are opened.
The interim solution is to use boost::interprocess::managed_windows_shared_memory to create the shared memory, but the desire is to use the generic version for cross-platform compatibility. If the full file path could be specified when creating the memory segment, it would solve the problem.
Soon to be released Boost 1.40 uses All Users Documents and Settings folder to build shared memory so that should work both for services and user processes. Adding configurability for the path would also be a good idea, maybe using an environment variable? Best, Ion
Ion: I think that configurability through an environment variable would work fine. Any ability to set the path would help, but being able to provide an argument to the constructor or some similar functionality would be best for our situation. Using All Users Documents and Settings seems like it would fix the service problem as well. But more options to set the location of the file would be optimal. Thanks, mlw
Date: Tue, 11 Aug 2009 19:17:19 +0200 From: igaztanaga@gmail.com To: boost@lists.boost.org Subject: Re: [boost] Control of the file location for the boost::interprocess::managed_shared_memory object
Michael Watkins escribió:
Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory?
No, sorry.
The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs to interface to the database that the service created.
Everything seems to work fine, but the service will open the shared memory backing file in the global temp directory while the user account will open the file in their local settings temporary directory. Therefore two different segments are opened.
The interim solution is to use boost::interprocess::managed_windows_shared_memory to create the shared memory, but the desire is to use the generic version for cross-platform compatibility. If the full file path could be specified when creating the memory segment, it would solve the problem.
Soon to be released Boost 1.40 uses All Users Documents and Settings folder to build shared memory so that should work both for services and user processes.
Adding configurability for the path would also be a good idea, maybe using an environment variable?
Best,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sy...
In the documentation for boost::interprocess, a lot of the container documentation is missing. For example, the 1.38 reference for boost::interprocess::slist contains useful documentation of the functions: http://www.boost.org/doc/libs/1_38_0/doc/html/boost/interprocess/slist.html However, the page in 1.39 or 1.40 is basically empty with a link to the header file. Is this intentional? http://www.boost.org/doc/libs/1_40_0/boost/interprocess/containers/slist.hpp Thanks, mlw _________________________________________________________________ With Windows Live, you can organize, edit, and share your photos. http://www.windowslive.com/Desktop/PhotoGallery
Michael Watkins escribió:
In the documentation for boost::interprocess, a lot of the container documentation is missing. For example, the 1.38 reference for boost::interprocess::slist contains useful documentation of the functions:
Sorry, this is a transition effect since containers were decoupled from Interprocess and proposed as Boost.Container. Documentation seems to be broken in the transition. I'll try to include the documentation again for the next version, or just remove it if Boost.Container is accepted. Thanks, Ion
participants (2)
-
Ion Gaztañaga -
Michael Watkins