[Top][All Lists]

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

Re: EINTR causing useless recompilation?

From: Paul D. Smith
Subject: Re: EINTR causing useless recompilation?
Date: Thu, 14 Nov 2002 12:52:01 -0500

%% Tom Rodriguez <address@hidden> writes:

  tr> Sorry about that.  I was using 3.79.  3.79.1 appears to do the
  tr> right thing and looking at the code it has a loop checking for
  tr> EINTR.  3.80 doesn't have the loop anymore but it does print a
  tr> message saying that stat was interrupted but it still performs the
  tr> useless recompilation.  It looks like some other delta may have
  tr> overridden the fix.

The loop was removed on purpose.

The problem is that there are many instances of stat() and lots of other
system calls, like readdir(), etc. which can also fail with EINTR during
parallel builds.

Going through all the code and wrapping every system call that could
fail in this way was not judged to be the best solution.

Instead, the code was changed to avoid the need for an EINTR check at
all, by enabling restartable system calls (SA_RESTART) on the signal
handlers.  Under SA_RESTART, the stat(2) system call should not fail
with EINTR at all; if it is interrupted by a signal it should restart
rather than returning EINTR.

If the GNU make configure script detects that your system doesn't
support SA_RESTART (because the constant is not defined) then it will
not enable -j support.

So, in your situation I see these possibilities:

 1) There's a bug in the way we've implemented the SA_RESTART change
    etc. where some signals still interrupt system calls when SA_RESTART
    is not active.

 2) Although your OS says it supports SA_RESTART, in fact it does not
    properly implement it.  I've already discovered another OS, Sequent
    PTX, which defines the SA_RESTART constant in the system header
    files, but it does not actually work.

    To the best of my knowledge SA_RESTART does work properly in Solaris
    2.7 and above (at least) on SPARC.  I've never tried it on x86.

 3) Something we haven't thought of.

 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

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