summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/cookerdata.py
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2015-09-29 09:28:24 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-10-01 07:43:38 +0100
commit1e467b333fe164a71404f3e3f6974440ce00e90f (patch)
tree781cb96d168c2734ff2e2b57ba9383c8cfadbea7 /bitbake/lib/bb/cookerdata.py
parente5b9c2a9f2b9ad354d246b20d7252957dd5ebb42 (diff)
downloadpoky-1e467b333fe164a71404f3e3f6974440ce00e90f.tar.gz
bitbake: bitbake-worker: Guard against multiprocessing corruption of event data
In the forked child, we may use multiprocessing. There is only one event pipe to the worker controlling process and if we're unlucky, multiple processes can write to it at once corrupting the data by intermixing it. We don't see this often but when we do, its quite puzzling. I suspect it only happens in tasks which use multiprocessng (do_rootfs, do_package) and is much more likely to happen when we have long messages, usually many times PAGE_SIZE since PAGE_SIZE writes are atomic. This makes it much more likely within do_roofs, when for example a subprocess lists the contents of a rootfs. To fix this, we give each child a Lock() object and use this to serialise writes to the controlling worker. (Bitbake rev: 3cb55bdf06148943960e438291f9a562857340a3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/cookerdata.py')
0 files changed, 0 insertions, 0 deletions