We definitely want timeouts. I was planning to implement timeout / gtimeout in C++ and checking it in and building it as part of the build process. But this would be better for obvious reasons.
On Wed, Sep 23, 2015 at 2:56 PM Todd Fiala <todd.fi...@gmail.com> wrote: > Yeah good idea. > > Anyways, that's what I'm going after. > > On the Windows front, is there any reason other than lack of > timeout/gtimeout why you wouldn't want timeouts? I'm trying to figure if > there is any reason I would want to work this in as an optional thing. > (Making it not optional would be slightly less complicated but either way > isn't particularly a big deal). > > -Todd > > On Wed, Sep 23, 2015 at 2:45 PM, Zachary Turner <ztur...@google.com> > wrote: > >> 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. >> >> On Wed, Sep 23, 2015 at 2:40 PM Todd Fiala <todd.fi...@gmail.com> wrote: >> >>> 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 >>> >> > > > -- > -Todd >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
