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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
