[distcc] re: distributed compiler cache

MartinPool mbp at samba.org
Thu Sep 12 13:58:00 GMT 2002

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:
>               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
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

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

A shared cache would always be accessed through the daemon, and so
everything would happen as a single uid.


More information about the distcc mailing list