<div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>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:</div><div>(non-Windows): --test-runner-name threading</div><div>(Windows): --test-runner-name threading-pool</div><div><br></div><div>There are a couple benefits here:</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thoughts?</div><div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>