<div dir="ltr">No obvious reason I see why that wouldn't work. You probably want to wrap the "thread 1" code in a try: ... except: pass because p.terminate probably will cause an exception on the other thread.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 23, 2015 at 2:40 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"><div dir="ltr">A nice bit here, also, is for those places where we are using timeout (Linux, OS X, etc.) we get to trade off and use a thread where we were using a whole different process. (i.e. the timeout wrapper process goes away).</div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 2:38 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yep - the approach (for now) is likely to look like:<div><br></div><div>p = subprocess.Popen(...) # exact call differs between Windows/Non-Windows</div><div><br></div><div>done_event = # some kind of semaphore/event, probably threading.Thread.Event()</div><div><br></div><div>spinup thread 1, running this code:</div><div> # Thread 1 - grab output, do communicate() call</div><div> p.communicate()</div><div> # Signal we finished - the process ended successfully.</div><div> done_event.signal()</div><div><br></div><div># ...back to the thread that called subprocess.Popen()</div><div><br></div><div># Wait for time timeout value for the inferior dotest.py process to complete..</div><div>timed_out = done_event.wait(timeout_in_seconds)</div><div><br></div><div># If timed_out indicates the timeout occurred, we timed out.</div><div># And thus, the process did not finish on time.</div><div>if timed_out == True:</div><div> # Kill the inferior dotest</div><div> p.kill() # or p.terminate()</div><div> # This will cause the other thread to fall through now, but we know it timed out.</div><div> # Could get fancier here and do a nice kill, then a less blockable kill. But make the</div><div> # process die one way or another.</div><div><br></div><div># do the other post-process activity here...</div><div><br></div><div><br></div><div><br></div><div>^= that's rough pseudo-code. I need to look up a few details. But that's more or less what I was thinking. Looked like all of that was available on Windows. We can also have it only optionally time out. </div><div><br></div><div>Something like that is what I had in mind.</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 2:28 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can you offer a hint about how you plan to implement this? When you say it we should get the same behavior everywhere, I assume this means Windows too, which currently does not support running with a timeout at all (because timeout / gtimeout aren't present)</div><br><div class="gmail_quote"><div><div><div dir="ltr">On Wed, Sep 23, 2015 at 2:22 PM Todd Fiala via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi all,<div><br></div><div>Over the last two days, I've hit some inconsistencies across platforms surrounding signal handling and the operation of the timeout/gtimeout executable mechanism that we use to handle timeouts of tests. The net result is I still see tests sometimes hang up the test running process, even though my changes in the last couple days seem to have reduced the frequency somewhat.</div><div><br></div><div>I'd like to address that once and for all with something that is less likely to differ across platforms. I have a relatively simple way to do that within the parallel test runner directly. I'm planning on prototyping that now, but before I dive too far into that, I wanted to expose the idea in case somebody had any major concerns with not using timeout/gtimeout on the systems that had it.</div><div><br></div><div>I expect it to be a relatively small change when I get it up for review.</div><div><br></div><div>The nice thing about going straight-python on it is we should get the same behavior everywhere, and not depend on signal handling to do it.</div><div><br></div><div>Thoughts?</div><div>-- <br><div><div dir="ltr">-Todd</div></div>
</div></div></div></div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div><div dir="ltr">-Todd</div></div>
</div></blockquote></div>