This is somewhat outdated. GNU make now uses named pipes by default on platforms that support it.

https://www.gnu.org/software/make/manual/html_node/POSIX-Job...

It's a bit more robust. For example when you have a Makefile like this:

    target:
        +python3 script.py $@

where `script.py` itself spawns a sub-process that is jobserver aware (like make, gcc, cargo, ...), you don't have to worry about whether the fds of the python process, needed for communicating with the jobserver, are inherited in the subprocess.

Previously you had to run `subprocess.Popen(..., close_fds=False)` and make sure MAKEFLAGS was inherited.

Now you only have to ensure MAKEFLAGS is propagated, and that the sub-process can access the fifo by path (which is sometimes problematic, for example when running docker).

Rust/Cargo has adopted this protocol: https://lib.rs/jobserver

so that comes quite right. Im currently working on a codebase that has evolved over 30-ish years. The makefiles are quite a mess and since ages, the software has been built sequentially which results in build times beeing much longer than required.

Of course the project consists of multiple module which you should be able to build seperately, thus recursive calls are quite common amongst the makefiles.

First test with only a hand full of jobs (-j) already failed in the beginning, i could fix these quite fast (missing makefile targets).

Now i have the situation that on some build systems (with faster CPU) i still see races, where the same makfile target for a subproject runs at the same time and overwrites each others target files. On other build systems it works without any issue. However, ive still failed to reproduce the failure manually, it usually happens during automatic build invoked by jenkins or gitlab.

Is there a way to make "make" simulate those builds so one could tell where the cause for the races is in detail?

> convincing myself that reads and writes of one-byte tokens to a pipe were atomic and robust

:)

It's interesting that waiting on a signal and a pipe read at the same time is the hard part. Would be interesting to track down how this happens to be implemented if you do this from a higher level async framework, like python's asyncio.