bug-make
[Top][All Lists]
Advanced

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

Re: Adjusting jobserver size (was: Re: No follow up on patches to suppor


From: Henrik Carlqvist
Subject: Re: Adjusting jobserver size (was: Re: No follow up on patches to support newer glibc ?)
Date: Mon, 13 Jul 2020 15:23:29 +0200

I have added an updated patch to bug #51200 and hope that you will reconsider
adding the functionality into next release. It is true that SIGUSR is already
used for debug toggling, but the behavior of SIGUSR1 isn't changed to
decreasing number of jobs until a SIGUSR2 signal is received. So make will be
fully compatible with its current behavior unless it receives a SIGUSR2 when
the new features kicks in and also replaces debug toggling.

The changes in my latest patch are:

* Adopted to new directory structure

* Making sure that no signal unsafe functions are called from the signal
  functions. To really make sure of this no other functions are called from
  signal functions. This means that both increasing and decreasing the number
  of jobs will not be done until a job finishes.

Best regards Henrik

On Sat, 07 Apr 2018 16:46:00 -0400
Paul Smith <psmith@gnu.org> wrote:

> On Thu, 2018-04-05 at 00:26 +0200, Henrik Carlqvist wrote:
> > On Wed, 04 Apr 2018 15:42:51 -0400
> > Paul Smith <psmith@gnu.org> wrote:
> > > It does look like we need to make a new release soon.
> > 
> > If so, is there anything I can do to get the functionality of my
> > contributed patch in bug #51200 into the upcoming new release?
> 
> Thanks for the reminder Henrik.  For those interested, the link is:
> https://savannah.gnu.org/bugs/index.php?51200
> 
> I'll confess I'm on the fence about this.  On the one hand I could
> imagine where it would be useful.
> 
> On the other hand, it's a complex change (I'm not convinced that your
> implementation is complete: for example, it's not immediately clear to
> me how the decrement handles the "free token" concept of the job server
> implementation... also, it's not a good idea to use fputs() in a signal
> handler, and I haven't traced down what other possible issues the other
> calls in increase_job_signal_handler() might have); it doesn't have
> testing with it to make sure it continues to work, and while useful in
> specific situations this feature likely won't be widely needed and so
> get less testing.  And it is limited to only working on POSIX systems
> as others don't support SIGUSRx (IIRC).  I get that we already use
> SIGUSR1 for debug toggling so there is precedent.
> 
> When I realize I started make with a jobserver value I don't like, I
> typically just kill the make and restart it.
> 
> _______________________________________________
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make



reply via email to

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