summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/namedtuple_with_abc.py
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2014-03-19 12:53:05 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-03-19 13:48:58 +0000
commitac4ff568f5b2ad4f50a1b7b60797e7b797c314bb (patch)
treed814ab087c7b583dec5e25e5bfb1b3bbd3963e39 /bitbake/lib/bb/namedtuple_with_abc.py
parentea52b5e21b71e0731ea0b8356770691b4b93d5be (diff)
downloadpoky-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