help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Passing jobserver file descriptors to all children


From: Paul Smith
Subject: Re: Passing jobserver file descriptors to all children
Date: Wed, 19 Feb 2020 15:37:05 -0500
User-agent: Evolution 3.34.1-2

On Wed, 2020-02-19 at 09:14 +0100, R. Diez wrote:
> Is there a way to tell GNU Make to always pass those jobserver file
> descriptors to all children?

There is nothing like that at the moment.

Originally make did pass these file descriptors to all children, but there
were bugs filed because some tools invoked by make expected to have
specific file descriptors available; having make pass down open FDs caused
them to fail.

I wouldn't be adverse to adding a way to allow this.

There is also an open bug asking that we do not pass along the jobserver
options at all if it's disabled.

Another option is to switch to a named pipe instead of an old-school pipe. 
In this case the thing we'd pass along to sub-makes would be the path of
the named pipe, so each tool that wanted to use the jobserver could open it
directly and we wouldn't need to pass along open file descriptors.  There
are some downsides to that, and we'd need to check the portability
situation with named pipes.

Are there any docs around the GCC usage of the jobserver?  I have a few
things I've been considering for jobserver enhancements; for example:

 * As above, switching to named pipes.  So, any code using the jobserver
   should be able to detect when the value of the jobserver argument is
   different than expected (not two integers), and handle it gracefully
   (ignore it, maybe with a warning or something).

 * Adding a new token type, maybe "-" or something, that was written to the
   jobserver if a command failed.  This would let us "fail faster".  This
   makes it very important that any user of the jobserver preserve the
   exact token they got and put it back into the pipe when done, rather
   than assuming it's always "+".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]