Re: GNU make jobserver redux

[Paul D. Smith]

%% Paul Eggert <address@hidden> writes:

  >> Yes, this is what I was suggesting.  That instead of installing the
  >> SIGCHLD handler at the start of the make process and leaving it there,
  >> we only install it when we're going to do the read, then after we get
  >> the token we put back SIG_DFL for SIGCHLD.

  pe> Mightn't SIG_DFL cause the read() to misbehave on the Hurd, for
  pe> reasons similar to why SA_RESTART misbehaves?

No; remember we're not setting SIG_DFL in the handler and expecting that
to interrupt the read().

The Hurd issue is that we're invoking a system call with a resource,
then during a signal handler we destroy that resource and expect the
system call to fail when it's restarted.  Even in POSIX this seems
suspect to me: there's certainly nothing I've seen that even implies it
will always work.  If I've missed it, let me know because Hurd wants to
be POSIX, so...

In the Hurd, the resource and the handle to it (the FD) aren't the same
thing; in make's SIGCHLD handler we actually only destroy the handle
(via close()) but the resource is still valid until later (at least as
long as the system call is using it, I guess).  Thus, the system call
does not fail when it's restarted.

In the SIG_DFL case we have the signal interrupt the read(), then
_after_ it returns completely we remove the handler to keep it from
interrupting any other system calls.

  pe> If the current code is working in the field, perhaps it would be
  pe> better to disable SA_RESTART instead; that is closer to what is
  pe> currently occurring.  Here's a proposed patch to implement that
  pe> idea; it replaces my earlier patch on this subject.  (This patch
  pe> also uses bsd_signal in a couple more places than the earlier
  pe> patch, to simplify the code.)

This looks similar to what I was thinking; I'll check it out.  Thanks.

The one difference is that I wasn't going to de-install the signal
handler until _after_ I actually got a token and was going to start a
job.  That is, the handler install would come before the token loop and
the de-install would come after the loop completed: the reap_children()
call would be inside the loop and still need to check for EINTR.

The idea was simply to avoid setting/unsetting signal handlers over and
over inside that loop.

However, your way is much safer if signal handler management is not
expensive... reap_children() has a well-defined set of code that it can
reach, but there's a decent amount of it.

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