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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
