[distcc] re: distributed compiler cache

[joerg.beyer at email.de]

distcc at samba.org schrieb am 12.09.02 15:58:04:
> On 12 Sep 2002, joerg.beyer at email.de wrote:
> > MartinPool <mbp at samba.org> schrieb am 12.09.02 15:00:04:
> > > > ok, now I see: if one process has a stats file locked and another
> > > > process will lock the same stats file, than the second process
> > > > will silently fail, because the fcntl(fd, F_SETLKW, &fl) in
> > > > util.c:lock_fd() will fail. Is this a problem? I am not sure.
> > > 
> > > It won't fail.  It will pause until the lock can be taken.
> > 
> > from the man page:
> >  F_SETLKW
> >               Like F_SETLK, but instead of returning an error  we
> >               wait for the lock to be released.  If a signal that
> >               is to be caught is received while fcntl is waiting,
> >               it is interrupted and (after the signal handler has
> >               returned) returns immediately (with return value -1
> >               and errno set to EINTR).
> > 
> > could fcntl return -1 with errno == EINTR in our situation?
> 
> I'm sorry, you're quite right.  But it looks like this function is

in this case the fix seem easy:

--- util.c_orig Thu Sep 12 16:26:14 2002
+++ util.c      Thu Sep 12 16:29:54 2002
@@ -241,6 +241,7 @@
 int lock_fd(int fd)
 {
        struct flock fl;
+    int rc;
 
        fl.l_type = F_WRLCK;
        fl.l_whence = SEEK_SET;
@@ -248,7 +249,10 @@
        fl.l_len = 1;
        fl.l_pid = 0;
 
-       return fcntl(fd, F_SETLKW, &fl);
+    do {
+           rc = fcntl(fd, F_SETLKW, &fl);
+    }while((rc == -1) && (errno == EINTR));
+    return rc;
 }

( I cc'd Andrew in case he is interested in this modfication)

> only called for updating the statistics file, and so the worst that
> can happen is that some parallel executions might not count towards
> the statistics.  Which is still perhaps worth fixing, but it is not
> terrible.
> 
> The to_cache and from_cache functions seem to use unix atomic-rename
> to move temporary files in and out of the cache, and so they are
> probably safe.  (Perhaps not on NFS, though.)
> 
> I didn't write ccache; I don't know the internals in detail.
> 
> > > At work we have several build machines which are shared by my
> > > colleague and I.  They run as me, but they work for both of us.  If
> > > they ran ccache through distccd it would work just as well. 
> > 
> > is your colleague compiling under his uid or under your uid?
> 
> On his workstation he runs distcc as his uid.  That makes a connection
> to distccd, which runs as my uid.  (In a proper installation, it might
> be a special purpose "distcc" user -- this is what the Debian package
> does.)  

ok, but for our environment (yours at work and the one I described)
it seem to suit better to have the cache on the only machine that 
does the precompilation, not all the machines that maybe help 
from time to time in compilation. In my setup the compilation nodes
will vary.

Martin:
Maybe I just bring my code to work (I believe in working code), put
it somewhere on sourceforge and then we could see if my concept
works at all :-) or which concept is better for which scenario.

After that I happily put it in the waste paper basket and we put the best
of both worlds into one project (presumably yours). What do you think
about that?

    Joerg