Re: [Boost-users] [interprocess] Lost communications and mysterious names

Subject: Re: [Boost-users] [interprocess] Lost communications and mysterious names
From: Roger (wuffles_at_[hidden])
Date: 2011-05-16 19:41:44

> From: "Ion Gaztañaga" <igaztanaga_at_[hidden]>
> To: Boost User List <boost-users_at_[hidden]>
> 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.