Question: I have a shared library(.so) that I preload before executing an application and I have a few global data structures in the shared library that the application uses. The application can create other processes say using fork() and these processes can update the global data structures in the shared library. I would like to keep a consistent view of these global data structures across all the processes. Is there any way I can accomplish this in Linux?

I have tried using shm\_\* calls and mmap() to map the global data of the shared library to a shared segment but it does not work.

Answer: 
If you only want to share the data with and among descendent processes (and not with arbitrary processes that are started up seperately, that just happen to link to the same shared library), then the easiest way to do this is have the library create a mapping with `mmap()` in a constructor function (that is called when the library is initially loaded in the parent process).

Pass the `MAP_ANONYMOUS` and `MAP_SHARED` flags to `mmap` - this will mean that child processes that inherit the mapping will have a mapping that is shared with the parent (and the other children). The library should then store data structures to be shared within that mmaped memory segment (just as if it was memory returned from `malloc`). Obviously you may need some kind of locking.

Constructor functions for libraries can be indicated using the `gcc` `__constructor__` function attribute.

You don't need to worry about cleaning-up this kind of shared memory - when the last process with an anonymous mapping exits, the memory will be cleaned up.
How about creating a simple pipe in a known directory location, then get other processes to fopen the pipe for reading/writing a la fread/fwrite respectively, to share data...the tricky part is ensuring that the data is passed through the pipe in a manner not to cause corruption in this case. The above you mentioned using shared memory shm\_ and mmap is tied to the process, when you fork code, that's no problem since the fork'd code is part of the original process! Hope this helps.

Best regards,
Tom.