Stefan Fuhrmann wrote on Thu, Oct 18, 2012 at 02:26:13 +0200:
> On Thu, Oct 18, 2012 at 1:57 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
>
> > Branko Čibej wrote on Mon, Oct 15, 2012 at 23:51:43 -0400:
> > > On 15.10.2012 17:14, Stefan Fuhrmann wrote:
> > > > However, if you have a long-running process like a server, that race
> > > > condition extends now extends over its whole lifetime. I.e. once a
> > > > revprop got read, any change to its value by a pre-1.8 tool may never
> > > > get detected.
> > >
> > > Ouch. This seems wrong. I'd understand a design like this if the
> > > long-running server were the only process accessing the repository, but
> > > that has never been the case in Subversion. In this case, a cache that
> > > can't detect out-of-band changes to the canonical dataset isn't very
> > useful.
> >
> > Another questionable part of the revprop cache: the
> > ATOMIC_REVPROP_TIMEOUT mechanism in fs_fs.c. (Basically, the code
> > assumes that if another process is rewriting a revprops file, it will
> > always finish within 10 seconds.)
> >
>
> Did you read and *understand* the code?
> What exactly will happen after the 10s timeout?
The two processes will have a different idea of what revprop
generation N is? One process will miss the other's changes?
I admit I wasn't really sure about the concrete kind of badness that
would happen if the assumption around ATOMIC_REVPROP_TIMEOUT ---
I changed my mind at least once while drafting the email --- but I'd be
surprised if no badness at all happens even if the assumption "the other
process must have crashed" turns out to be wrong. (If that is the case,
why does the comment mention the assumption at all?)
Received on 2012-10-18 22:46:51 CEST