[lldb-dev] Moving test runner timeout logic into Python

[Zachary Turner via lldb-dev]

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.fiala at 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 <zturner at 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.fiala at 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.fiala at 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 <zturner at 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 at 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 at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -Todd
>>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>
>
> --
> -Todd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150923/4c7459ff/attachment-0001.html>