From: "Ion Gaztañaga" <igaztanaga@gmail.com> To: Boost User List <boost-users@lists.boost.org> Date: Wed, 11 May 2011 21:20:54 +0200 Subject: Re: [Boost-users] [interprocess] Lost communications and mysterious names El 10/05/2011 23:18, Roger escribió:

...

I'm using boost 1.46 on windows XP and I am having occasional issues with interprocess.  Sometimes I lose communications between programs. I've located the directory where the files that enable the interprocess communication are created.  Usually the files have the name I provide to the managed_shared_memory object in the code. However, when the problem occurs a file named something like "70C0A8E6490FCC01E55D313B550FCC01" appears.  When the programs terminate this file disappears, while the normally named files persist.

That name is produced when you unlink the shared memory. Code renames in-use file and marks it as delete-on-close so that it's really erased when any attached program ends. This emulates unix-like unlink behaviour. Are you unlinking the shm while in use?

best,

Ion

I was using shared_memory_object::remove(name), if that's what you mean by unlinking. Actually I'd already solved my problem before I even asked the question - I just accidentally commented that bit out. What I was doing was periodically reopening the shared memory in processes that were reading only. So if another process removed and recreated it, it would eventually find the new copy. Is this a sensible way to do it? Is there a function to test whether the memory has been removed? The only reason I was recreating the shared memory was to ensure a cleanly initialised empty space. Perhaps I should turf the whole recreating process and go with a clearing process instead. That should be fine once what I'm sharing is fixed. But during development it can change, and I recall the programs crashing if they open an old file and try to read a variable which wasn't there in the old version.