Re: [Boost-users] boost.interprocess dynamic segment size?

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2008-04-13 04:46:42

Zeljko Vrba wrote:
> The one process that allocates the memory for the new list element in its
> shm_malloc() will do (roughly, some steps omitted from the previous post):
> 
> - take the dedicated mutex
> - grow and map the segment in its own private address space
> - allocate the chunk of memory again (this must succeed now!)
> - asynchronously interrupt other processes

Ok. You need to register all processes attached to one particular 
segment the segment somewhere. This imposes some reliability problems 
because a process might crash when doing another task than using the 
segment.

An asynchronous notification via signal does not carry enough context 
(sigval from sigqueue onlyl stores an int or void*) to notify which 
growable shared memory segment should other processes remap. This would 
require generating an unique id from the shared memory name. A process 
can have more than one growable shared memory segment.

And if that does not discourage you from implementing this, there is no 
much you can do inside a signal handler. You can see a list here:

http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_04.html#tag_02_04

This means that you can't call mmap from a signal handler. You can't 
remap memory asynchronously according POSIX. It's possible that some OSs 
support that.

If remapping is possible, a more correct and robust mechanism could be 
catching SIGSEGV from processes that have not updated their memory 
mappings and doing some remapping with some global growable segment list 
stored in a singleton (this has problems when using dlls). Less 
interprocess communication means more reliability.

Regards,

Ion