[lldb-dev] changing default test runner from multiprocessing-based to threading-based

[Todd Fiala via lldb-dev]

Hi all,

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
threaded version.

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.

Thoughts?
-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150921/736bb824/attachment.html>