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