[lldb-dev] Moving test runner timeout logic into Python
Zachary Turner via lldb-dev
lldb-dev at lists.llvm.org
Wed Sep 23 14:45:51 PDT 2015
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
> 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
>> spinup thread 1, running this code:
>> # Thread 1 - grab output, do communicate() call
>> # Signal we finished - the process ended successfully.
>> # ...back to the thread that called subprocess.Popen()
>> # Wait for time timeout value for the inferior dotest.py process to
>> 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>
>>> 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.
>>>> lldb-dev mailing list
>>>> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev