On Thu, Jul 21, 2022 at 10:23 AM Paul Smith <psm...@gnu.org> wrote:
> Instead, any sub-process can look at MAKEFLAGS, see the value of
jobserver-auth, find the name of the pipe, open it, and start to use
it.  If the sub-process doesn't know anything about MAKEFLAGS, it will
never know that the jobserver is relevant.  If the sub-process knows
about it, it can participate.  Everything is up to the sub-process and
nothing is required of the parent make.

There are clearly lots of benefits here.
There is also a change in behavior.
make-4.3 lets the user control (via presence or absence of +) if a particular
sub-process should participate in the jobserver business.
The current master, on the other hand, is "everyting is up to the sub-make".
E.g.
all:; make -C src
In the case of make-4.3 the sub-make does not participate.
In the case of master the sub-make participates.

> Semaphores would be the same: we pass down the NAME of the semaphore,
and each sub-process that cares would use it.  But as I discovered we
can't use semaphores because we don't have a reliable way to create an
event handler that works both with semaphores and with SIGCHLD (that I
could find), other than polling which I don't like.

It is pselect which does not work with a semaphore.
However, it is possible to use a semaphore and sigchld w/o pselect.
i actually built a prototype which uses a posix semaphore. The algorithm is
the same as the original pipe based algorithm, which predates pselect. The only
difference is that in the pipe algorithm the race between
read and sigchld is solved by having sigchld handler close the dup fd. In
this algorithm the race is solved by having sigchld handler post the semaphore.
The difficult part is the free token. If there was no concept of a
free token, then any
sigchld could post the semaphore. However, in the case of the child
that used the
free token, the semaphore should not be posted. This forces tricky
book keeping and
basically renders the whole algorithm as too complex.

> The downside is we need to write code to manage the named pipe
resource.

Another downside is that any unrelated process which has sufficient privileges
(same eid or root) can mess up the named pipe.

regards, Dmitry

Reply via email to