Avoid syscalls
mccoyst opened this issue · 7 comments
These aren't covered by the Go compatibility promise and are questionably portable. I at least want to get rid of the Wait4 polling, because it's orthogonal to the race described in #14 (which was due to global PID flim-flammery).
The race fixed by Wait4 is between wait and kill, not the pids. You don't
want to send kill to a process after wait has returned, because then you
may kill a different process which was unlucky enough to get allocated that
same pid. With the polling scheme, kill is only ever sent if wait has yet
to return the process exit status, so you are always killing the intended
process.
On Wed, Jun 10, 2015 at 3:00 PM Steve McCoy notifications@github.com
wrote:
These aren't covered by the Go compatibility promise and are questionably
portable. I at least want to get rid of the Wait4 polling, because it's
orthogonal to the race described in #14
#14 (which was due to global PID
flim-flammery).—
Reply to this email directly or view it on GitHub
#22.
We should use Cmd.Process.Kill instead of a kill that takes a PID.
Does that kill the whole process group?
On Wed, Jun 10, 2015, 17:13 Steve McCoy notifications@github.com wrote:
We should use Cmd.Kill instead of a kill that takes a PID.
—
Reply to this email directly or view it on GitHub
#22 (comment).
No, but I think that's a hopeless road to go down… Nothing stops the subprocesses from going into disjoint groups (and again, portability). I'll understand if that's a dealbreaker for you, though.
It's a deal breaker. Nothing stops it, but it also doesn't happen. Build
processes aren't creating daemons, but they may fork off.
I'm not concerned about system call API stability. If wait4 changes (it
won't), we'll fix it. I'm also not overly concerned with portability. It
works on Linux, and you indicate that it works on osx. That's good enough
for me. If it works on BSD or Windows, great, but I'm not going to break
one of my most heavily used tools for myself to cater to those systems.
On Wed, Jun 10, 2015, 17:18 Steve McCoy notifications@github.com wrote:
No, but I think that's a hopeless road to go down… Nothing stops the
subprocesses from going into disjoint groups (and again, portability). I'll
understand if that's a dealbreaker for you, though.—
Reply to this email directly or view it on GitHub
#22 (comment).
No problem, but FYI the compatibility promise isn't that wait4 may change, but that syscall.Wait4 may be removed at any time.
It'll be fine. If it goes away well use cgo :-)
On Wed, Jun 10, 2015, 17:48 Steve McCoy notifications@github.com wrote:
No problem, but FYI the compatibility promise isn't that wait4 may change,
but that syscall.Wait4 may be removed at any time.—
Reply to this email directly or view it on GitHub
#22 (comment).