On Wed, Jun 24, 2020 at 10:42 PM Brian Candler <b.cand...@pobox.com> wrote:
>
> My problem is actually around exec.CommandContext. I mentioned
> os.Process.Kill is because that's the interface that exec.CommandContext uses:
>
> > The provided context is used to kill the process (by calling
> > os.Process.Kill) if the context becomes done before the command completes
> > on its own.
>
> It would be fine to change only exec.CommandContext to do the right thing:
> *if* the process was started with Setsid, *and* we're running on Unix, then
> call unix.Kill with negative pid - otherwise fall back to os.Process.Kill.
> Would that be reasonable?
>
> Alternatively, could you provide a hook for a user-defined killing function?
Ah, I see. I'm not sure whether this is a good idea or not.
exec.CommandContext is essentially a helper function. It doesn't do
anything you can't do yourself. Basically it starts a goroutine that
does
select {
case <-c.ctx.Done():
c.Process.Kill()
case <-c.waitDone:
}
where c.waitDone is a channel that is closed when cmd.Wait returns.
You could do that yourself with a bit of work. So the question is
whether the chance of increased complexity and potential confusion in
CommandContext is worth changing the way that it works. There are
other problems with it too--not everyone wants their program killed
outright. But we've avoided adding a hook, as you suggest, because
it's relatively easy for someone to do whatever they want anyhow.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWv8aFDgapZA-PLTMFoGcshX9qHt27M7xEGThG_%3DVz9bA%40mail.gmail.com.
