The patch below adds a new "--threads" option whose default value is "multiprocessing.cpu_count()". And only if "multiprocessing.cpu_count()" returns 0 will it fall back to using the LLDB_TEST_THREADS environment variable. I am not sure why the environment variable was ever used instead of using an option.
If everyone can try out this patch and make sure it does things as expected:
dosep.patch
Description: Binary data
I will check it in if all goes well. Greg On Mar 17, 2014, at 10:34 AM, Ed Maste <[email protected]> wrote: >>> Maybe "@serializeTest"? >> >> That's worth a try. > > I have a slight worry that this approach could mask real concurrency > issues in LLDB itself; if we know that the issues are only in the test > code it seems more reasonable. Even in that case though tests could > run concurrently on the same machine, e.g. a buildbot host that builds > and tests multiple configurations. > >> In the event that your idea works out to eliminate those failures, there is >> another element we can consider. We can have Python give us the # cores >> available (if there's something portable to do that), and when not otherwise >> specified, pick a reasonable default # threads to get decent test run >> performance without needing the environment variable specified. This would >> give anybody running the tests a decent test run speedup without having to >> read docs on configuring the environment variable. (I think this was Steve >> Pucci's idea but definitely something we discussed.) > > I was going to make that suggestion too. Python does have a portable > way to get the core count: > >>>> import multiprocessing >>>> multiprocessing.cpu_count() > 8 > > Anyhow, explicitly serializing the tests that intermittently fail > would be no worse than today, and worth it to improve the cycle time.
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
