parallel_emerge: Suppress multiprocessing exceptions during shutdown.
parallel_emerge: Suppress multiprocessing exceptions during shutdown.

Specifically, due to multiprocessing sucking, we wind up seeing the
following quite frequently (line wrapped):

<parallel-emerge output>
Done
Exception in thread QueueFeederThread (most likely raised during
  interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 525, in __bootstrap_inner
  File "/usr/lib64/python2.6/threading.py", line 477, in run
  File "/usr/lib64/python2.6/multiprocessing/queues.py", line 233, in _feed
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

Roughly, this (and those like it) come about due to threads still
in existance during late vm shutdown.  Those threads are around due
to multiprocessing leaving those threads to be GC'd while marking
the threads as daemon (meaning the VM *can* shutdown regardless of
if they're still running).

Needless to say, this is stupid.  This is fixed in 2.7 via
http://bugs.python.org/issue4106.  We're not on 2.7 however, and
I'm tired of seeing this noisy traceback.

This CL basically manipulates the shutdown in a similar fashion,
suppressing this fully in my testing (under enough load, it may
still be possible for the error to slip out; that would be forkbomb
levels of load I suspect).

Roughly, addressing this via:
1) Reduced the pointless sys.exit usage; that triggers an Exception,
  resulting in the vm strongly refererencing the traceback which
  strongly references each frame it crashed through.  One way to
  keep instances around.
2) Explicitly forcing of gc collection.  In testing, this tactic alone
  seems to be enough to suppress the TB although that's mostly timing.
  The step is necessary either way to ensure that PyFinalize's GC
  run doesn't get first crack at these threads (if it does, by that
  time the VM is mid shutdown thus the exception).
3) Explicitly go looking for those damn threads and try to join them
  with a 1 second timeout.  In testing, this tactic alone seems to be
  enough to suppress the TB.  This is basically a variation of what
  the upstream fix was.

BUG=None
TEST=None, realistically.  Fundamentally it's a race; heavy system
     load seems to exacerbate it's frequency, but this can very.
     Having a build_packages running in the background (full load)
     while abusing setup_board to create a new target from scratch
     was the recent 75% scenario- that said that scenario has broken
     down in the past (right now locally, it's occuring, thus this
     patch.  YMMV however).

Change-Id: I2c7c63b23a75808fd33eeefb05d70e73c8463b99
Reviewed-on: https://gerrit.chromium.org/gerrit/23340
Tested-by: Brian Harring <fdc2d0a2e2340b623587cee5ea8dff425d1eb1f3@chromium.org>
Reviewed-by: David James <f231dc574bbeb62604660cbc162d1b8642a0a3af@chromium.org>
Commit-Ready: Brian Harring <fdc2d0a2e2340b623587cee5ea8dff425d1eb1f3@chromium.org>

bpsinc-native/src_third_party_chromite,chadversary/chromiumos.chromite,zhang0137/chromite,coreos/chromite,bpsinc-native/src_third_party_chromite,bpsinc-native/src_third_party_chromite,zhang0137/chromite,coreos/chromite,zhang0137/chromite,chadversary/chromiumos.chromite,coreos/chromite