Shared Memory
-
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid? Todd Smith
-
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid? Todd Smith
-
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid? Todd Smith
-
I believe that if the process that creates the name file mapping exits, the mapping no longer exists.
Thomas George wrote: I believe that if the process that creates the name file mapping exits, the mapping no longer exists. So what happens when the other processes try to read/write the file mapping? KABOOM? Is it possible for the other processes to know when the main process has closed the file mapping? I guess you could create a mutex or something and check that before using the file mapping. Todd Smith
-
Thomas George wrote: I believe that if the process that creates the name file mapping exits, the mapping no longer exists. So what happens when the other processes try to read/write the file mapping? KABOOM? Is it possible for the other processes to know when the main process has closed the file mapping? I guess you could create a mutex or something and check that before using the file mapping. Todd Smith
Actually, docs say that you HAVE to use Structured Exception Handling because the system could produce access violations (even in situations, when both are active). You will certainly get an access violation when the second app tries to access the shared memory; but I am yet to find out how the second app can find out that the file mapping no longer exists. I am not aware of any events. Thomas
-
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid? Todd Smith
I believe that because the FileMapping object is a Kernel object, that the file mapping will continue to exist until all handles to it are released. Here is an excerpt from the CreateFileMapping functions remarks section in MSDN: To fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile, and close the file mapping object handle by calling CloseHandle. The order in which these functions are called does not matter. The call to UnmapViewOfFile is necessary because mapped views of a file mapping object maintain internal open handles to the object, and a file mapping object will not close until all open handles to it are closed.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid? Todd Smith
Paul wrotes: I believe that because the FileMapping object is a Kernel object, that the file mapping will continue to exist until all handles to it are released. Paul is absolutely right here. A (named) file mapping is a kernel object and will exists, until the last handle to it has been closed. So in your scenarion the mapping will still be present and valid, because at every time there is at least one valid handle to it. BTW: Using native NT Api it is even possible to make a kernel object "persistent", meaning that it would continue to exist after the last handle to it has been closed (persistent means until next reboot). Of course this makes sense only for named kernel objects. Even if sometimes fairly useful, this is undocumented and therefore "not recommended" :-( -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D )