<div dir="ltr">I'm testing a fix for this locally.  Hold tight</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 3, 2015 at 3:33 PM Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tfiala added a comment.<br>
<br>
In <a href="http://reviews.llvm.org/D12587#239639" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12587#239639</a>, @zturner wrote:<br>
<br>
> I actually am seeing this now, I'm not sure why I didn't see it earlier,<br>
>  the only thing I can think of is that the patch didn't apply successfully<br>
>  even though I thoguht it did.<br>
><br>
> When I stop at this line:<br>
><br>
>   if num_threads > 1:<br>
>       pool = multiprocessing.Pool(<br>
>           num_threads,<br>
>           initializer=setup_global_variables,<br>
>           initargs=(output_lock, test_counter, total_tests, test_name_len,<br>
>                     dotest_options))<br>
><br>
><br>
> in a debugger and inspect the value of dotest_options,<br>
>  `dotest_options.no_multiprocessing` is set to False.  Is this correct?  It<br>
>  seems like for the child dotest instances, it shouldn't be trying to<br>
>  recursively do this multiprocessing?<br>
<br>
<br>
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.<br>
<br>
<br>
<a href="http://reviews.llvm.org/D12587" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12587</a><br>
<br>
<br>
<br>
</blockquote></div>