RE: [PATCH] kill all threadapply processes at end of test

[Carl Love via Gdb-patches <gdb-patches@sourceware.org>]

Tom, Simon:

On Thu, 2021-05-13 at 10:30 -0400, Simon Marchi wrote:

> From what I can see, there is not attach in that test, only
> detach.  GDB
> starts some processes itself, and tests that detaching in a "thread
> apply" command is correctly handled.  It's these processes that are
> detached that are left running.  Fortunately, they exit when the
> threads' counters go past INT_MAX, making the condition `*myp > 0`
> false.  Unfortunately, it means they consume a lot of CPU for some
> time after the test.

Yes, that is a correct summary of the issue.

On Thu, 2021-05-13 at 09:44 -0600, Tom Tromey wrote:
> > > > > > "Carl" == Carl Love via Gdb-patches <
> > > > > > gdb-patches@sourceware.org> writes:
> 
> Carl> +# Make sure all of the threadapply processes are terminated
> Carl> +set data [exec ps -e | grep threadapply]
> 
> This seems like an issue in a few ways.  'ps' arguments may differ by
> platform.  Other programs might be called 'threadapply' (unlikely for
> user stuff but suppose I'm running 2 gdb test suites at the same
> time).
> It doesn't handle cross-host testing (I don't know if we care about
> that
> any more but in the past it was an issue).
> 
> So, I wonder if there's a better way to do this.
> Like, could the test track PIDs itself?  Then maybe re-attach?

I had tried to do that but couldn't get the code to work.

On Thu, 2021-05-13 at 10:30 -0400, Simon Marchi wrote:
> Instead, could we
> redesign the test so there isn't this CPU-consuming loop?  Maybe use
> a pthread barrier, such that when we detach, the all threads are
> released and the program ends immediately.  I don't know if that will
> cause complications because the threads' backtraces won't be exactly
> predictable, but it would good to give this a try.

Interesting idea.  I will give this a try.  If it doesn't work out, I
will go back and work on the re-attach approach some more to see if I
can get that to work.

Thanks for the help.

                    Carl