Re: GNU make jobserver redux

[Paul D. Smith]

%% Paul Eggert <address@hidden> writes:

  >> .. reap_children() has a well-defined set of code that it can
  >> reach, but there's a decent amount of it.

  pe> Yes, that was mostly my concern.  I don't know the code as well as
  pe> you do, so I played safe.  Also, I had the vague (and perhaps
  pe> incorrect) impression that the loop normally iterates only once,
  pe> so there's not that much benefit to hoisting the code out of the
  pe> loop.

Normally you're right.  There are only unusual circumstances where we'd
go through that loop more than once.

  pe> I also toyed with the idea of mutating your test program into an
  pe> autoconfiguration gizmo that would let 'make' avoid the signal handler
  pe> management on hosts that don't need it, but decided I didn't have the
  pe> time -- and anyway, a build-time test might not give results that are
  pe> reliable for run-time, e.g. failures might occur only on
  pe> multiprocessor hosts.

Yes, I thought of trying to configure it, too.  But besides the
complexity of the configure test, it would also add to the complexity of
the make code to try to maintain two different algorithms for this, so
I'd prefer to avoid that anyway.

  pe> By the way, I looked at POSIX.1-200x draft 6, and it wasn't very clear
  pe> on the subject.  So I proposed adding the following to the rationale:

  pe> "If a signal-catching function returns while the SA_RESTART flag is in
  pe> effect, an interrupted function is restarted at the point it was
  pe> interrupted.  Portable applications cannot make assumptions about the
  pe> internal behavior of interrupted functions, even if the functions are
  pe> async-signal-safe.  For example, suppose the read() function is
  pe> interrupted with SA_RESTART in effect, the signal-catching function
  pe> closes the file descriptor being read from and returns, and the read()
  pe> function is then restarted; in this case the application cannot assume
  pe> that the read() function will give an [EBADF] error, since read()
  pe> might have checked the file descriptor for validity before being
  pe> interrupted."

The Hurd folks should be happy about that :).

Thanks.

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