On Tue, Oct 30, 2012 at 6:58 PM, Philip Martin <philip.mar...@wandisco.com>wrote:
> 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. > Excellent analysis, Philip! With r1404112, we use "plain" APR mmap code with almost no coding overhead. The only downside is that we now have a temporary file sitting in the db folder. As for the Windows code, mmap is being used for shared memory there as well - so it should just work. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
