[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EINTR causing useless recompilation?

From: Tom Rodriguez
Subject: EINTR causing useless recompilation?
Date: Wed, 13 Nov 2002 11:32:45 -0800

I've got a large piece of software, the Java Hotspot Virtual Machine,
and we use GNU make for the builds. I've noticed in the past that
incremental builds sometime recompile more things than are necessary. 
Today I hit it again and decided to investigate.  Touching 2 .cpp
files causing 4-6 files to get recompiled.  If I invoke make with the
-d option to print it why those files are being recompiled causes only
the 2 touched files to be recompiled, which indicates some sort of bug
in make to me.  Using truss to track system calls indicates that
sometimes stat fails with EINTR and this appears to cause make to
consider these files to be out of date.  The latest make-3.80 even
prints out a message saying that the stat was interrupted but it still
recompiles the files.  I'm curious why the stat isn't simply retried
when EINTR is returned as I would expect.  Given the heavy use of GNU
make I'd expect it to do the right thing in this regard.  I can
recompile with --disable-job-server and the problem goes away but
since this isn't the normal configuration, it sure would be nice if
GNU make didn't simply fail when stat returns EINTR.  By the way, this
is on Solaris x86.  Linux seems to work correctly.  I think I've seen
this problem on Solaris sparc but I don't have a repeatable case.

I think the proper fix is to check for EINTR in name_mtime the same
way it is checked in touch_file, like this:

*** /tmp/remake.c       Wed Nov 13 11:26:07 2002
--- remake.c    Wed Nov 13 11:27:47 2002
*** 1212,1219 ****
       register char *name;
    struct stat st;
!   if (stat (name, &st) < 0)
      return (FILE_TIMESTAMP) -1;
--- 1212,1223 ----
       register char *name;
    struct stat st;
+   int status;
!   do
!     status = stat (name, &st);
!   while (status < 0 && EINTR_SET);
!   if (status < 0)
      return (FILE_TIMESTAMP) -1;

This fixes the problem for me.


Tom Rodriguez
Hotspot Client Compiler Technical Lead

reply via email to

[Prev in Thread] Current Thread [Next in Thread]