Re: Some "fun" last weekend

[Paul Smith]

On Wed, 2022-07-20 at 00:47 -0400, Dmitry Goncharov wrote:
> On Tue, Jul 19, 2022 at 6:13 PM Paul Smith <psmith@gnu.org> wrote:
> > There are at least two Savannah bugs about this very subtle and
> > annoying issue.
> 
> Do you mean that jobserver-auth is present in the child env, even
> though the fds are closed?

Yes, that.

> > you get different output: the environment variable DOES contain the
> > extra option, but the make variable does not.  The behavior of
> > these things is subtle enough already, it seems unpleasant to make
> > it even more complex.
> 
> Looks good to me.

I dunno.  There are so many ways this can bite people.  The last thing
GNU make needs IMO is more obscure subtleties.  For example if someone
writes this:

  NRMAKE = $(MAKE)

  recurse:
          MAKEFLAGS=$(MAKEFLAGS) $(NRMAKE)

it will break.  Likewise if you do something similar with $(shell ...)

If it was the case that MAKEFLAGS was an off-limits and had always been
documented that way, maybe I'd feel less nervous about it.  But people
are always messing about with MAKEFLAGS in their makefiles and using it
in odd ways.

But, I suppose since I already implemented it I could push these
changes; at least things work better than they did before.  Then if we
do create a new implementation based on named pipes or whatever, we
wouldn't need this.  But likely even if we do create a new
implementation we'll have to support the old implementation, since it
could be that a new version of make is being invoked as a submake of an
old version (or, I guess, vice versa... that would be a bummer.  Needs
to be considered.)

>  At least i'd prefer a pipe and this (or similar) quirk over all the
> disadvantages of named pipes.

Just to be clear when you say "all the disadvantages of named pipes"
are you referring to the ones I mentioned in my email, or are there
other disadvantages that should be considered as well that I didn't
mention?

> 
> If you are willing to have a platform specific impl, then linux has
> eventfd.  https://man7.org/linux/man-pages/man2/eventfd.2.html.

True, but I think we have enough options that we don't need to resort
to Linux-only features.  I would prefer to be portable wherever
possible.  eventfd doesn't solve the fundamental problem of select vs.
SIGCHLD, any better than our current implementation options do, as far
as I can see.

> One portable impl to have a semaphore with a fd is to use a pipe.
> sem_init opens a pipe.
> sem_post writes one byte to the pipe.
> sem_wait blocks on reading one byte from the pipe.

Sorry I didn't quite follow this.  Are you suggesting that we create
our own implementation of sem_* that works this way?  I don't see any
way to get the POSIX sem_init to open a pipe, etc.

If so, I think this basically exactly how the current jobserver
implementation in GNU make works, isn't it?  It won't help with the
issues we have, AFAICT.