On Sat, 2021-05-22 at 00:59 +0200, Steffen Nurpmeso via austin-group-l at The Open Group wrote: > Then stating something like "i am process X, and my parent is Y" > etc. And the rest being up to the make(1) implementor as a quality > of implementation (scheduling, fair even more so, seems to reside in > the area of very complicated programming). I was surprised to see > that rule content matters at all.
The problem is that depending on the implementation, the parent make might need to pass actual resources to the child make instance. Those resources could negatively impact child processes that are NOT make. In that case, make needs to know whether the thing it is invoking is another make or not, so it knows whether to pass those resources. As an example, in GNU make today we use a simple pipe to implement this feature, which means child makes need to have the open file descriptors for the ends of the pipe provided to them when they are started. But, some other programs that are not make, might not work well if they are invoked with extra file descriptors already open, and if they write garbage into the jobserver pipe then it will break things. So in this implementation make would want to close-on-exec those file descriptors before invoking the sub-process, IF it knows the sub-process is not a make instance. Of course, for an implementation which can assume POSIX most likely this is NOT the method that would be chosen to implement the jobserver as it leads to complications. GNU make, however, is part of a system bootstrap toolchain (needed to build a compiler for an old system to start to update it for example) so I try to keep it portable to very old systems. Nevertheless, I've been considering switching GNU make's implementation to a named pipe (mkfifo) or a POSIX semaphore. These implementations would resolve all the above issues (and others, such as blocking/non- blocking FDs etc.) since only a sub-make would access the named pipe. Anyway, that's not really relevant but just FYI as to why (I suspect) the standard was worded like this.
