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
