[Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.

[Todd Fiala via lldb-commits]

tfiala added a comment.

In http://reviews.llvm.org/D12651#240480, @zturner wrote:

> Tried out this patch, unfortunately I'm seeing the same thing.  The very
>  first call to worker.join() is never returning.
>
> It's unfortunate that it's so hard to debug this stuff, do you have any
>  suggestions for how I can try to nail down what the child dotest instance
>  is actually doing?  I wonder if it's blocking somewhere in its script, or
>  if this is some quirk of the multiprocessing library's dynamic invocation /
>  whatever magic is does.
>
> How much of an effort would it be to make the switch to threads now?  The
>  main thing we'd have to do is get rid of all of the globals in dotest, and
>  make a DoTest class or something.


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.

> As a last resort, you can bring back the pool.map logic behind an OS check,

>  and use the multiprocess.Process logic for other platforms.  But it would

>  be great to have less platform specific branches and logic, not more.

> 

> I'm willing to bet you could reproduce this on a Windows VM with a trash

>  script that all it does is create some processes using the same structure

>  of loop you're using here.  Not sure if that's an option for you.  I don't

>  mind the back and forth diagnostics either, just whatever is easiest for

>  you.


Yeah I will have to get a Windows LLDB setup going again.  I've got one at home so I can try with that in the near future here.  For the moment I'm going to throw up one with multiprocessing.Pool again and throw it over the wall after I make sure Ctrl-C is working with it here (OS X and Linux).

I will try to get the Pool-based version going now.  Back as soon as I have that!


http://reviews.llvm.org/D12651