diff options
author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2014-03-19 12:53:05 +0000 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2014-03-19 13:48:58 +0000 |
commit | ac4ff568f5b2ad4f50a1b7b60797e7b797c314bb (patch) | |
tree | d814ab087c7b583dec5e25e5bfb1b3bbd3963e39 /bitbake/lib/bb/namedtuple_with_abc.py | |
parent | ea52b5e21b71e0731ea0b8356770691b4b93d5be (diff) | |
download | poky-ac4ff568f5b2ad4f50a1b7b60797e7b797c314bb.tar.gz |
bitbake: runqueue: Revert child signal handler for now
We're running into processes using 100% cpu. It appears theses are locked in
a subprocess.poll() type loop where the process has exited but the code is
looping as its not handling the ECHILD error.
http://bugs.python.org/issue14396
http://bugs.python.org/issue15756
This is likely due to one or both of the above bugs. The question is what actually
grabbed the child exit code as it wasn't this code. Its likely there is therefore
some other code racing and taking that code, it may be some kind of race like:
http://hg.python.org/cpython/rev/767420808a62/
where the fix effectively catches the childs codes in a different part of the system.
We could try and get everyone onto python 2.7.4 where the above bugs are fixed however
for now its safer to admit defeat and go back to polling explictly for our worker exit
codes.
(Bitbake rev: 5b9a099ec2a1dc954b614e12a306595f55b6a99e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/namedtuple_with_abc.py')
0 files changed, 0 insertions, 0 deletions