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).
On Wed, Sep 23, 2015 at 2:38 PM, Todd Fiala <todd.fi...@gmail.com> wrote: > Yep - the approach (for now) is likely to look like: > > p = subprocess.Popen(...) # exact call differs between Windows/Non-Windows > > done_event = # some kind of semaphore/event, probably > threading.Thread.Event() > > spinup thread 1, running this code: > # Thread 1 - grab output, do communicate() call > p.communicate() > # Signal we finished - the process ended successfully. > done_event.signal() > > # ...back to the thread that called subprocess.Popen() > > # Wait for time timeout value for the inferior dotest.py process to > complete.. > timed_out = done_event.wait(timeout_in_seconds) > > # If timed_out indicates the timeout occurred, we timed out. > # And thus, the process did not finish on time. > if timed_out == True: > # Kill the inferior dotest > p.kill() # or p.terminate() > # This will cause the other thread to fall through now, but we know it > timed out. > # Could get fancier here and do a nice kill, then a less blockable > kill. But make the > # process die one way or another. > > # do the other post-process activity here... > > > > ^= 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. > > Something like that is what I had in mind. > > On Wed, Sep 23, 2015 at 2:28 PM, Zachary Turner <ztur...@google.com> > wrote: > >> 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) >> >> On Wed, Sep 23, 2015 at 2:22 PM Todd Fiala via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi all, >>> >>> 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. >>> >>> 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. >>> >>> I expect it to be a relatively small change when I get it up for review. >>> >>> 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. >>> >>> Thoughts? >>> -- >>> -Todd >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> > > > -- > -Todd > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
