Cool. Win win :-)
On Wed, Sep 23, 2015 at 2:57 PM, Zachary Turner wrote:
> 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,
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 wrote:
> Yeah good idea.
>
> Anyways, that's what I'm goi
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 sli
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 wrote:
> A nice bit here, also, is for those places where
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 wrote:
> Yep - the approach (fo
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
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 F
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 t
