On Tue, Oct 30, 2012 at 6:58 PM, Philip Martin
> Philip Martin <philip.martin_at_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.
Certified & Supported Apache Subversion Downloads:
Received on 2012-10-31 13:32:57 CET