On Mon, Mar 01, 2010 at 06:14:33PM +0000, Julian Foad wrote:
> On Thu, 2010-02-18, Neels J Hofmeyr wrote:
> > The one thing left now is:
> > > Can someone explain a motivation for even creating a database row before
> > > the pristine file is moved into place in the pristine store? I currently
> > > don't see why it can't be way simpler.
> [...]
> "Simultaneous or multi-threaded clients" would be my first reaction to
> that particular question.
If two threads write to the same pristine, the content written
will be the same (except in case of a SHA1 checksum collision
which we choose to ignore). So, thread 1 writes to a tempfile, and
when it's done, it moves the tempfile into place. The new filename
of the tempfile being based on the SHA1 sum of the written content.
If thread 2 does the same concurrently, the end result will be the
same -- the file will only exist once at its SHA1 sum name.
Of course, writing the same pristine more than once is redundant.
So we could try to optmize this redundancy away. But I don't think
it is worth it. If you're only talking about threads within a single
process, it's fairly easy. But if you're talking about multiple
processes using the same pristine store concurrently with mutual
exclusion, you need inter-process communication to deal with stale locks.
What is a process supposed to do with a locked pristine store, if
it has no way of telling what happened to the process which locked
the pristine store? What if the other process has chrashed?
Stefan
Received on 2010-03-01 19:33:00 CET