<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 4, 2015 at 5:10 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/D12651#240480" rel="noreferrer" target="_blank">http://reviews.llvm.org/D12651#240480</a>, @zturner wrote:<br>
<br>
> Tried out this patch, unfortunately I'm seeing the same thing.  The very<br>
>  first call to worker.join() is never returning.<br>
><br>
> It's unfortunate that it's so hard to debug this stuff, do you have any<br>
>  suggestions for how I can try to nail down what the child dotest instance<br>
>  is actually doing?  I wonder if it's blocking somewhere in its script, or<br>
>  if this is some quirk of the multiprocessing library's dynamic invocation /<br>
>  whatever magic is does.<br>
><br>
> How much of an effort would it be to make the switch to threads now?  The<br>
>  main thing we'd have to do is get rid of all of the globals in dotest, and<br>
>  make a DoTest class or something.<br>
<br>
<br>
It's a bit more work than I want to take on right now.  I think we really may want to keep the multiprocessing and just not exec out to dotest.py for a third-ish time for each inferior.<br></blockquote><div><br></div><div>Just to clarify, are you saying we may want to keep multiprocessing over threads even if you can solve the exec problem?  Any particular reason?  Multi-threaded is much easier to debug, for starters, because you can just attach your debugger to a single process.  It also solves a lot of race conditions and makes output processing easier (not to mention higher performance), because you don't even need a way to have the sub-processes communicate their results back to the parent because the results are just in memory.  stick them in a synchronized queue and the parent can just process it.  So it would probably even speed up the test runner.</div><div><br></div><div>I think if there's not a very good reason to keep multiprocessing around, we should aim for a threaded approach.  My understanding is that lit already does this, so there's no fundamental reason it shouldn't work correctly on MacOSX, just have to solve the exec problem like you mentioned.</div><div><br></div><div><br></div></div></div>