[Lldb-commits] [PATCH] 5 minute timeout for tests
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
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...
More information about the lldb-commits