I'm testing a fix for this locally. Hold tight On Thu, Sep 3, 2015 at 3:33 PM Todd Fiala <todd.fi...@gmail.com> wrote:
> tfiala added a comment. > > In http://reviews.llvm.org/D12587#239639, @zturner wrote: > > > I actually am seeing this now, I'm not sure why I didn't see it earlier, > > the only thing I can think of is that the patch didn't apply > successfully > > even though I thoguht it did. > > > > When I stop at this line: > > > > if num_threads > 1: > > pool = multiprocessing.Pool( > > num_threads, > > initializer=setup_global_variables, > > initargs=(output_lock, test_counter, total_tests, > test_name_len, > > dotest_options)) > > > > > > in a debugger and inspect the value of dotest_options, > > `dotest_options.no_multiprocessing` is set to False. Is this correct? > It > > seems like for the child dotest instances, it shouldn't be trying to > > recursively do this multiprocessing? > > > That flag is only meaningful to the initial invocation. It would be False > if the user didn't specify it on the command line in the highest-level > process that is driving the parallel test runner. That looks fine. > > > http://reviews.llvm.org/D12587 > > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
