Thanks for your feedback! > 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...
The variable decrease_jobs is set to 0 unless a SIGUSR1 has been received. With decrease_jobs set to 0 the code in free_child will behave as without my patch applied, if we have a job server and jobserver_tokens > 1 a job will be released to the job server and our own remaining jobserver_tokens will be decreased by 1. If SIGUSR1 has been used one or more times decrease_jobs will have a value bigger than 0. Then the code in free_child will still decrease jobserver_tokens by 1 but instead of relasing the job back to the job server the variable decrease_jobs will be decreased by 1. That way the function free_child will make sure that from now on one less parallell job is being run by make as was intended by one received SIGUSR1. > also, it's not a good idea to use fputs() in a signal > handler, I can remove those printouts like "Decreased number of jobs to %d" as they are not necessary for the functionality, they are only a help to the user to see what is going on. > 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, If you so wish, I can also remove those initializing jobserver-function calls from the signal handler. Without those function calls it will no longer be possible to increase number of jobs unless make initially was started with the -j flag. The call to jobserver_release could also be moved out of the signal handler, but that would be at the cost of having to wait for the next finished job before an extra new job will be spawned. For that reason I would prefer to keep the call to jobserver_release and add a big fat comment in (at least the posix version of) jobserver_release that no non reentrat code might be added to that function. > And it is limited to only working on POSIX systems as others don't > support SIGUSRx (IIRC). This is true, if you have any idea for a more portable solution I am willing to rewrite my patch. I am also willing to implement different solutions for different environments, but I am only able to test on Linux (posix) myself. > When I realize I started make with a jobserver value I don't like, I > typically just kill the make and restart it. This usually works fine for a normal compile. But make can be used for so much more than compiling programs. Some processes started by make might need a long time to finish and restarting them might be costful for different reasons. I understand that my patch as it looks now is not going to make it into the next release. However, as I find its functionality useful I am willing to put more work into the patch if it will help. I am also willing to sacrifice the ability to add jobs if make was started without "-j" and any helpful output from the signal handlers. regards Henrik _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
