[Lldb-commits] [PATCH] D13124: test runner: switch to pure-Python timeout mechanism

[Zachary Turner via lldb-commits]

If I understand correctly, the process hierarchy used to look like this:

python - dotest.py
|__ python - multiprocessing fork
      |__ python - lldbtest
            |__ inferior executable

And now looks like this:

python - dotest.py
   |__ python - lldbtest
         |__ inferior executable

In either case, the process.terminate() runs in the python - lldbtest
process, and terminates the inferior.  So I don't see how the behavior is
any different than before.  Do you mean with gtimeout it's creating a
separate process group for the inferior so that if the inferior itself
spawns children, those will get cleaned up too?  Do any inferiors actually
do that?  And if so, we could always use the same logic from python of
creating the inferior in a separate process group

On Thu, Sep 24, 2015 at 3:36 AM Pavel Labath <labath at google.com> wrote:

> labath added a comment.
>
> I don't want to stand in the way of progress (and I do think that getting
> rid of the timeout dependency is progress), but this implementation
> regresses in a couple of features compared to using timeout:
>
> - timeout tries (with moderate success) to cleanup children spawned by the
> main process. your implementation will (afaik) kill only the main process.
> This is especially important for build bots, since leaking processes will
> starve the bot's resources after a while (and we have had problems with
> this on our darwin build bot).
> - we intentionally had timeout terminate the child processes with SIGQUIT,
> because this produces core files of the terminated processes. I have found
> this very useful when diagnosing the sources of hanging tests. I'd like to
> have the possibility to do this, even if it will not be enabled by default.
>
> Do you think that the benefits of this change outweigh these issues? If
> so, and they don't cause our bots to break, then we can put it in (and i'll
> probably implement the code dumping feature when I find some time), but I
> though you should be aware of these downsides.
>
>
> http://reviews.llvm.org/D13124
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150924/c494d604/attachment-0001.html>