Re: [Bug-gnulib] addition: wait-process.h, wait-process.c

[Bruno Haible]

Paul Eggert wrote:
> > > If waitpid fails with errno == EINTR, a signal handler was run.
>
> Not necessarily, unfortunately.  It is a fairly common bug that system
> calls like waitpid can return with errno == EINTR even though no
> signal handler was run.  SIGCONT is a common culprit.  I've seen
> the bug both with AIX and with Linux.

I've seen read() also return with errno == EINTR, on early Solaris. Be it
a bug or not. What I wanted to say is: If waitpid fails with errno == EINTR
and some subprocess status has changed, a signal handler was run. That's
all we need to know.

> > > Specifically, diffutils' checksigs() could call exit (EXIT_TROUBLE)
> > > after longjmping back to main, no?
>
> I suppose it might be able to, if we can assume POSIX semantics.  But
> isn't it safer to stick with the C89 semantics that it currently uses,
> where it merely stores into a volatile int variable?  That way, I
> don't have to worry so much about handling signals at arbitrary
> points.

Yes I agree.

> Here are some more details about the tricky situation in sdiff.c, if
> you're interested.  Sdiff can be interrupted while a child is running.
> If the signal handler were to exit right away, then sdiff would exit
> even though its child was still running.  Sdiff wants to kill off its
> child in that situation, but it shouldn't just send a signal to the
> child's pid, since the child may already have been reaped and a new,
> unrelated process may have taken its place.  The current code
> sidesteps all this mess

The 'pipe' module (also on my list for inclusion in gnulib) does the
same thing as 'sdiff' does: spawning a subprocess, connecting it with
the main process via pipe(), and read from the pipe. So I have to ask
  - Is this complicated subprocess killing round necessary at all?
    IMO, the subprocess is killed anyway a short time after the main
    process, simply because it produces output, and writing to a closed
    pipe kills the writer process. So is it just bloat in sdiff, or
    a flaw in the pipe*.c functions in GNU gettext?
  - sdiff.c also does a lot of other signal handling stuff. Is this
    useful in general?

> I see that I didn't mention this earlier in this old thread, but
> bison's lib/subpipe.c has a function reap_subpipe that doesn't have
> all the functionality of wait_subprocess (as Bison doesn't need it),
> but has some extra stuff (e.g., support for status 126) that
> wait_subprocess lacks.

I already explained why I don't wish support for status 126 not to be
contained in wait-process.c: because it's not a universal convention.
(It's a convention at the shell level only, not at the posix_spawn level.)

But this is no contradiction with the way Bison does it: The read_subpipe
function could call wait_subprocess() and handle the status code 126
by itself. The only status code that wait_subprocess() deals with is 127,
on the grounds that POSIX specifies the semantics of status code 127
in its posix_spawn() description.

> I briefly looked at
> <http://mail.gnu.org/archive/html/bug-gnulib/2003-04/msg00020.html>
> and noted a potential portability problem: "*(int *) &status = 0;"
> looks a bit suspicious.  Surely hosts that don't allow using 'int' for
> a wait status are long dead; are they still worth worrying about?

That's not a portability problem, it's a portability fix :-) Namely
for those hosts where 'union wait' is used instead of 'int'; this includes
NeXTstep 3 and therefore probably also OpenStep and MacOS X.

Bruno