(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 <[email protected]> wrote: > On Mon Dec 01 2014 at 4:05:25 PM Chaoren Lin <[email protected]> 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. >
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
