[Lldb-commits] [PATCH] D12651: Add ctrl-c support to parallel dotest.py.
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Fri Sep 4 16:40:10 PDT 2015
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.
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
On Fri, Sep 4, 2015 at 4:29 PM Todd Fiala <todd.fiala at gmail.com> wrote:
> tfiala added a comment.
> Hey Zachary,
> Can you give the latest patch a try? That might stop some unintentional
> blockage as adding items to those two queues would be blocking.
> I'm going to be relocating home in a minute, but the other thing I'm going
> to try is to go back to the multiprocessing.Pool() and see if the Ctrl-C
> woes that others hit are maybe somehow not an issue for us. If that's the
> case, then maybe the Pool() piece will take care of whatever isn't happy on
> the Windows side with the manual pooling.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits