[interprocess] Different processes accessing shared memory in different locations
Hi Our application has the following scenario using Boost V1.0.52: 1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\... 2) Process A launches Process B 3) Process B attempts to read from shared memory but fails. It is attempting to read from: C:\Users\<username>\AppData\Local\Temp\boost_interprocess\... This failure only occurs on one single Windows 8 64 bit machine out of many we have tested. On all other machines, the application works perfectly. Please could somebody advise: What changes to our application could be made to avoid this? What changes to the machine's configuration (eg. Registry) could be made to avoid this issue? Many thanks Thomas Sanham
El 10/09/2013 12:01, Tom Sanham escribió:
Hi
Our application has the following scenario using Boost V1.0.52:
1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\...
2) Process A launches Process B
3) Process B attempts to read from shared memory but fails. It is attempting to read from: C:\Users\<username>\AppData\Local\Temp\boost_interprocess\...
This failure only occurs on one single Windows 8 64 bit machine out of many we have tested. On all other machines, the application works perfectly.
If you look in boost/interprocess/detail/tmp_dir_helpers.hpp: #if defined (BOOST_INTERPROCESS_WINDOWS) winapi::get_shared_documents_folder(tmp_name); if(tmp_name.empty() || !winapi::is_directory(tmp_name.c_str())){ tmp_name = get_temporary_path(); } #else if shared documents folder is not found, then the temporary path is used. The shared documents folder is found in the registry in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData Hope it helps, Ion
On 11/09/2013 3:50 a.m., Quoth Ion Gaztañaga:
if shared documents folder is not found, then the temporary path is used. The shared documents folder is found in the registry in the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData
That's the wrong way to do it. You should instead call either SHGetKnownFolderPath (on Vista+) or SHGetFolderPath (on -XP). Don't forget to pass the flag that requests creation of the folder if it doesn't already exist.
Yes that does help. Thank you very much. We fixed the registry on the PC in question and the problem is now solved. Tom -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztanaga Sent: Tuesday, September 10, 2013 4:51 PM To: boost@lists.boost.org Subject: Re: [boost] [interprocess] Different processes accessing shared memory in different locations El 10/09/2013 12:01, Tom Sanham escribió:
Hi
Our application has the following scenario using Boost V1.0.52:
1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\...
2) Process A launches Process B
3) Process B attempts to read from shared memory but fails. It is attempting to read from: C:\Users\<username>\AppData\Local\Temp\boost_interprocess\...
This failure only occurs on one single Windows 8 64 bit machine out of many we have tested. On all other machines, the application works perfectly.
If you look in boost/interprocess/detail/tmp_dir_helpers.hpp: #if defined (BOOST_INTERPROCESS_WINDOWS) winapi::get_shared_documents_folder(tmp_name); if(tmp_name.empty() || !winapi::is_directory(tmp_name.c_str())){ tmp_name = get_temporary_path(); } #else if shared documents folder is not found, then the temporary path is used. The shared documents folder is found in the registry in the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData Hope it helps, Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/09/2013 10:01 p.m., Quoth Tom Sanham:
Our application has the following scenario using Boost V1.0.52:
1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\...
This doesn't really address your issue, but something that puzzles me about this report is: why are files being used for shared memory at all? I'm not really familiar with Interprocess so maybe I'm missing something fundamental, but I can't think of any good reason to use an on-disk file if you just want some IPC shared memory. (It would be useful only if you want persistent storage in case the two processes are not actually running at the same time, which seems like a very unusual scenario for IPC.) (And there are permissions issues with accessing files in CommonAppData, which could explain the OP's problem if the library doesn't address them.)
participants (3)
-
Gavin Lambert -
Ion Gaztañaga -
Tom Sanham