summaryrefslogtreecommitdiff
path: root/meta/recipes-devtools/unifdef
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2011-01-28 10:21:41 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-01-28 10:21:41 +0000
commit06c6db7929c75f576a395fb442abe447b833fc3b (patch)
treec62b8db28f74cc9cce6e84a7a70bab1be4fa986f /meta/recipes-devtools/unifdef
parent754047b6ec01df5f3159cce93b17b8493d0af5e1 (diff)
downloadopenembedded-core-06c6db7929c75f576a395fb442abe447b833fc3b.tar.gz
openembedded-core-06c6db7929c75f576a395fb442abe447b833fc3b.tar.bz2
openembedded-core-06c6db7929c75f576a395fb442abe447b833fc3b.tar.xz
openembedded-core-06c6db7929c75f576a395fb442abe447b833fc3b.zip
bitbake/runqueue.py: Avoid starvation of events to the server
The server UI was reading 1024 bytes, then sleeping for 0.25 seconds. Since most new LogRecord events are larger than this it leads to a build up of data which is only processed slowly, leading to a bottleneck and a slow down of all bitbake processes. Thanks to Dongxiao Xu <dongxiao.xu@intel.com> for the great work in debugging this. A large value has been left in for the read() command just to ensure some fairness amongst process handling if a task tries to log truly huge amounts of data to the server, or goes crazy and ensures the main loop doesn't stall. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-devtools/unifdef')
0 files changed, 0 insertions, 0 deletions