[Lldb-commits] [PATCH] 5 minute timeout for tests

Zachary Turner zturner at google.com
Mon Dec 1 16:17:06 PST 2014


(You may still want to verify that there's no objections from other
stakeholders whose platforms aren't supported by the "timeout" command
though.)

On Mon Dec 01 2014 at 4:16:04 PM Zachary Turner <zturner at google.com> wrote:

> On Mon Dec 01 2014 at 4:05:25 PM Chaoren Lin <chaorenl at google.com> wrote:
>
>> "timeout 5m %s %s/dotest.py %s -p %s %s" will kill python after 5
>>> minutes, but will it also kill any inferiors, and descendants of those?
>>> And what if you have A > B > C, and B dies, then you kill A's tree?
>>
>>
>> As far as I can tell with my experimentation, timeout actually handles
>> all of those cases perfectly.
>>
>> launching the process in a process group ("job" on windows)
>>
>>
>> Could we do that portably?
>>
>> If it's not important then it seems like just running the process in a
>>> separate thread with a timeout would be sufficient.
>>
>>
>> I think it's important. Since otherwise you'll finish the test but still
>> end up with a bunch of processes taking up resources in the background.
>>
>
> I thought about it some more, and I think the best solution will be to
> have a python extension module that implements timeout on each platform.
> Then we could use it like this:
>
> import timeout
>
> timeout.run("5m", program, **args)
>
> On Linux and FreeBSD, this would jsut call the system command, and on
> Windows it would create the process in a job from a separate thread with
> timeout, and kill the parent process if the tiemout expires, and on OSX it
> could do something else.  For any platform which doesn't provide an
> implementation, it could just run the process normally.
>
> This doesn't matter for Windows at the moment since we don't have a
> Windows bot anyway, so if you want to check in the original patch for the
> time being, that's fine (as long as it's behind an OS check, so I don't get
> errors about the timeout command not existing) and we can do the module
> once we actually need it.
>
> It's still not platform independent, but at least all the platform
> specific stuff will be isolated to its own module, and it would be nice to
> introduce a place where platform specific python code could live behind a
> platform agnostic abstraction anyway.  There's already a lot of platform
> specific stuff in lldbtest.py that would be great to abstract away.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20141202/4c286b06/attachment.html>


More information about the lldb-commits mailing list