Exit explicitly at end of parallel_emerge, so child processes exit as well.

Exit explicitly at end of parallel_emerge, so child processes exit as well.

So, we've been seeing parallel_emerge hang after printing "Done". It's hard to
know for sure why this hang is happening, but my theory right now is that the
Python garbage collector doesn't always know that it needs to kill the child
processes when we exit normally at the bottom of the script. Adding sys.exit(0)
tells Python that yes, we really want to exit.

I haven't tested my hypothesis above, because the hang we've been seeing is
pretty rare and is hard to reproduce. So I'm planning on testing by just
putting in this workaround and seeing if it fixes the problem.

TEST=Run ./parallel_emerge world
BUG=chromium-os:5976
Change-Id: I7b4f2ec4ccba9b00f22f3739dfd3eff51ceed425

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=5137a74

[Nick Sanders, 2010-09-29 22:03:35]

lgtm, hope it fixes it!

[kliegs, 2010-09-29 22:25:56]

Would adding in a call to print out child processes be more useful for
debugging?  If we think that's the problem then when we see a process hung
we can see the output of how many child processes were present and draw
a correlation.

While this change may fix the problem, determining if it worked or if we've
just been lucky will be difficult.

On Wed, Sep 29, 2010 at 6:03 PM, <nsanders@chromium.org> wrote:

> lgtm, hope it fixes it!
>
>
>
> http://codereview.chromium.org/3448030/show
>

[David James, 2010-09-29 23:07:30]

On 2010/09/29 22:25:56, kliegs wrote:
> Would adding in a call to print out child processes be more useful for
> debugging?  If we think that's the problem then when we see a process hung
> we can see the output of how many child processes were present and draw
> a correlation.

If we see it hang again, that'd be a good step. We could add in a timer that
checks if parallel_emerge is still trying to exit after some timeout and then
outputs the debug messages if necessary. But I think that would be overkill if
my current commit fixes the problem.


> While this change may fix the problem, determining if it worked or if we've
> just been lucky will be difficult.

We've already seen this problem 3 times, so, if the problem is still present,
we'll likely see it fail again. If that happens again we can look into adding
more debugging stuffs.

Cheers,

David