Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking

[Robin Farine]

On Saturday 05 June 2004 00.07, Jan Hudec wrote:
> On Fri, Jun 04, 2004 at 22:20:58 +0200, Robin Farine wrote:
> > On Friday 04 June 2004 20.56, Jan Hudec wrote:
> > > On Fri, Jun 04, 2004 at 15:41:13 +0100, Andrew Suffield
> > > wrote:
> >
> > [...]
> >
> > > > If the link succeeds and the link count on the lock file is
> > > > 2, you have the lock. Otherwise you missed: delete the lock
> > > > file and your temporary file, wait a random interval, and
> > > > try again.
> >
> > I would say this is wrong.
> >
> > > Still the same.
> >
> > No, if one cared about the success of the link operation, then
> > one would not need a temporary file. The successfull creation
> > of a hard
>
> Hell, that's what we talk about whole day! *YOU* *CAN'T* *RELY*
> *ON* *THE* *RETURN* *VALUE*.

That's exactly why I said that what Andrew described is not the same 
as the original algorithm. 

> > link to a well-known existing file would suffice to acquire the
> > lock. And if the result of the link operation is not reliable,
> > then testing the link count of the lock file does not help at
> > all.
>
> It does. If you are the only one trying to link something to a
> specified file, than it's link count can only ever increase if
> YOU succeed. And that's what you want to know.

Sorry but I was talking about the _lock file_ which link count is 
always 2 when the lock is owned, the owner being you or another 
guy, thus the link count of the _lock file_ won't help. What 
matters is the link count of the _temporary file_.


Robin