Justin Erenkrantz <justin@erenkrantz.com> writes:
> --On Wednesday, December 8, 2004 12:15 PM -0600 "C. Michael Pilato"
> <cmpilato@collab.net> wrote:
>
> > My suggestion is that libsvn_fs_base grows the same serialization that
> > mod_db4 uses, which is based around the use of a shared memory segment
> > with a reference count in it. Can we make use of apr_atomics for
> > something like this?
>
> So, would we add a named shared memory segment that resides underneath
> the repository - i.e. the locks subdirectory? If so, then, yes apr's
> shmem routines would be able to map it in.
Nono. This must be done at the libsvn_fs_base level, preferably
stored in the db/ directory.
> However, APR's atomics can't provide any guarantees outside of a
> single process. If the hardware/OS supports atomics, then it does,
> but the APR fallback atomic code relies upon thread mutexes. So, we'd
> have to use some type of file lock as well - perhaps the db.lock we
> already use for recover as well? -- justin
Okay, so no go on the atomics. Locking is fine, but again, must be
done in libsvn_fs_base (not libsvn_repos). In other words, we do this
at the lowest reasonable level at which a program might hook into our
Berkeley DB environment. Obviously, we can't do anything about
programs that try to read our tables directly (bypassing our APIs)
... but shame on those program anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 8 19:43:30 2004