Re: Race in svn_atomic_namespace__create

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.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download