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

[Todd Fiala via lldb-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150923/3b6ae87f/attachment-0001.html>