Subject: Re: make: adding .KILL ?
To: Christos Zoulas <christos@zoulas.com>
From: Simon J. Gerraty <sjg@crufty.net>
List: tech-toolchain
Date: 11/01/2006 16:26:22
>| > I don't like the SIGKILL and I don't understand the reason for the sleep()s
>|
>| The sleeps are there to give the process time to get scheduled (and exit)
>| before the kill -9.
>sched_yield()?
Does such a thing exist outside of netbsd?
>| However the code ought to send all the jobs SIGTERM, then wait (and reap)
>| a bit for them to die, then (maybe) send SIGKILL - rather than sleeping
>| 2 seconds for every job.
>I agree. I think process groups is a nice way to manage this.
Agreed. At this stage I'm as much interested in feedback on the
general usefulness of a .KILL special src. It's useful to me but
maybe not others.
Unless something changed recently, I think make is already signaling the
relevant process groups btw.
>| In any case make won't be looking for a job-token unless it has has
>| additional tasks to run (and hasn't reached its own job limit).
>| So you'd also have to catch SIGTERM itself and attempt to do the tidy up.
>| That will fall fould because the parent make is likely to SIGKILL it
>| while it is still waiting to terminate any children that are ignoring
>| SIGTERM.
>|
>| You also need to treat the exited jobs in the normal way - ie delete
>| the (possibly partially made) target.
>Yes, that too :-)
IIRC we've already deposited an abort token, before starting the slaughter.
Would it be appropriate to just SIGINT everyone and then wait for them to
bail - ie. don't use Job_AbortAll() for this, but something similar.
Worst case would be similar behavior to current.
I used Job_AbortAll() for this patch just to verify it would solve my
problem (of build continuing long after it was doomed).
Thanks
--sjg