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#t... 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