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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
