Philip Martin <philip.mar...@wandisco.com> writes: > That's a serious problem, the two processes are not longer using the > same shared memory segment to keep in sync. Changes made by one process > won't be visible to another.
I don't see how to fix this with the current APR code. The process that creates the named shared memory will always delete the associated file at pool cleanup and that stops further processes attaching. I guess this is designed for a server where the parent process passes shared memory to child processes but it doesn't really fit our model of independent processes. I think we would have to change APR to get this to work. An alternative approach would use anonymous shared memory and have Subversion itself manage the ID outside APR (storing it in the lock file perhaps) but APR doesn't support that either: APR doesn't make the ID available or support attaching to anonymous shared memory. Again, we would have to add support to APR and then require the new APR version. Another approach would be to create the shared memory created from some other, long-lived, process. The user would have to run this process to enable caching. To handle a large number of repositories this would probably have to be some sort of daemon. Perhaps we could use apr_mmap_create instead? APR doesn't specify whether the mmap is SHARED or PRIVATE but the current implementation on Unix is shared. I don't know enough about Windows to understand how that implementation behaves. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
