[Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Todd Fiala via lldb-commits
lldb-commits at lists.llvm.org
Fri Sep 4 17:10:09 PDT 2015
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
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!
More information about the lldb-commits