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