Stefan Sperling wrote:
> 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.
Yup, the file will be OK.
I didn't have any specific failure mode in mind, and I can't think of
one now. If there is some reason, then we can tackle it when we find
the reason.
+1 on KISS.
> 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. [...]
Agreed.
- Julian
Received on 2010-03-02 10:46:05 CET