Re: [Boost-users] shmem - Allocating enough space. open and allocate.

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-10-22 07:25:32

Hi Andrea,

> I implemented successfully a program to delivery grabbed images to
> clients for display purposes ...
> Really fine ...
> 
> But it seems to me that the remove method doesn't work.
> 
> For example after killing the grabber process and I open again
> a Gui to display images, no (ipc) exceptions are thrown and the gui
> displays the last grabbed image.
> 
> The process that grabs, before quitting calls:
> 
> shared_memory_object::remove(mem_obj_tag.c_str());
> (the shmem was created with open_or_create)
> 
> and the process that reads opens the shared memory in read_only mode.

Remove does not throw any exception, just returns true or false. Check i 
false is being returned. If the shared memory segment was opened while 
trying to delete it, it's possible on some platforms (win32) not to be 
able to delete the segment. This is similar to standard std::remove 
function. In windows, usually calls DeleteFile, that fails if another 
process has opened the file. In Unix, unlink() is called, and the file 
is removed from the filesystem, but processes still work in that unnamed 
file. This is the non-portable problem of trying to emulate shared 
memory in Windows with the same semantics as in Unix.

I think I should see what Boost.Filesystem does with remove(onst path & 
ph) and do the same. There are 3 possible options:

-> The shared memory segment does not exist
-> The shared memory segment exists but it can't be deleted
-> The shared memory segment exists and its deleted

The problem for a different solution for each one is that we must 
atomically check the existence and remove the file, and that's not easy 
because it must be atomic regarding other processes. The Shmem big 
global lock is not a very good idea, so I will try to think something 
about it. Definitely I think I should follow Boost.Filesystem rationale.

Regards,

Ion