Re: Make does not clean up the target when stderr is piped. Why?

[Paul Smith]

On Fri, 2021-06-04 at 14:17 -0700, Kaz Kylheku (gmake) wrote:
> The applicable standards like POSIX may say so as a blanket general
> statement. For instance of a signal goes off while we are executing
> free() and we call malloc() in the handler, that is obviously bad.
> 
> But if we block the signal, and only unblock it in safe situations
> (like around long I/O operations, or invocations of external
> programs), then we are actually okay.

The problem is not that, the problem is race conditions.  In GNU make
we need to worry about two completely different types of events: we
need to be able to wait for signals, such as child process exiting or
SIGINT, and we need to wait for data to appear on a file descriptor
(for jobserver support).

Waiting for both of these two things in a reliable way without losing
either one is hard in POSIX.  This is why pselect() was invented but of
course that is not portable to older systems and non-POSIX systems.

There are alternatives like using the old "internal pipe" trick which
requires using select (or similar) so you can wait on multiple file
descriptors.  Unfortunately in the past even select() hasn't been
completely portable (it accepted different orders of arguments on some
systems).  Those systems may be too obsolete to worry about anymore.

> > I have a partial solution to fix it, but it's actually extremely
> > difficult due to the really crappy signal handling model that POSIX
> > provides and my current solution still suffers from race conditions
> > that need to be resolved before it can be used.  I haven't had time
> > to get back to this.
> 
> Oh, the model will sit up and beg if you give it the right milk
> bones.

I didn't say "impossible", I said "extremely difficult" :).

> I think your main difficulty is working in in a widely portable and
> fundamental GNU program. There are still some VMS ifdefs in this
> thing and such. I.e. that GNU Make perhaps still has to run on
> systems which have broken POSIX signal handling.

Yes, clearly that's true.  If I could use all the very latest libc
features it would be much less of a problem.

Just to note: actually VMS is an actively maintained port.  The ports
that are almost certainly obsolete these days are Amiga and maybe the
very old DOS version.  Windows and VMS are still in active use.

> In this situation, when that handler is running, it might make sense
> to block SIGPIPE. POSIX has the wherewithal to arrange that.

Sure.  But any code change to GNU make won't be available until a new
release, and I'd just as soon fix the underlying mistake in a new
release than work around this one particular issue.