[lldb-dev] changing default test runner from multiprocessing-based to threading-based
Todd Fiala via lldb-dev
lldb-dev at lists.llvm.org
Mon Sep 21 12:49:02 PDT 2015
I'm considering changing the default lldb test runner from
multiprocessing-based to threading-based. Long ago I switched it from
threading to multiprocessing. The only reason I did this was because OS X
was failing to allow more than one exec at a time in the worker threads -
way down in the Python Global Interpreter Lock (GIL). And, at the time, I
didn't have the time to break out the test runner strategies.
We have verified the threading-based issue is no longer manifesting on OS X
10.10 and 10.11 beta. That being the case, I'd like to convert us back to
being threading-based by default. Specifically, this will have the same
effect as doing the following:
(non-Windows): --test-runner-name threading
(Windows): --test-runner-name threading-pool
There are a couple benefits here:
1. We'll remove a fork for creating the worker queues. Each of those are
just threads when using threading, rather than being forked processes.
Depending on the underlying OS, a thread is typically cheaper. Also, some
of the inter-worker communication now becomes cheap intra-process
communication instead of heavier multiprocessing constructs.
2. Debugging is a bit easier. The worker queues make a lot of noise in 'ps
aux'-style greps, and are a pain to debug relatively speaking vs. the
I'm not yet looking to remove the multiprocessing support. It is likely
I'll check the OS X version and default to the multiprocessing test runner
if it wasn't explicitly specified and the OS X version is < 10.10 as I'm
pretty sure I hit the issue on 10.9's python.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev