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

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

Pedro:

On Tue, 2021-05-18 at 21:11 -0300, Pedro Franco de Carvalho wrote:
> Hi Carl,
> 
> Another thing, regarding pthread_barrier_wait solution that Simon
> suggested.  I'm not sure, but I think the idea would be to initialize
> a
> barrier with a count of as many threads as are created in the test,
> plus
> the main thread.  Then you'd put a call to pthread_barrier_wait
> before
> the exit from the thread_function, and remove the busy loop.  This
> will
> be called by all the created threads shortly after they are created,
> but
> they won't exit until the main itself thread also calls
> thread_function
> and then pthread_barrier_wait.  Assuming the breakpoint in /* Break
> here
> */ for main happens before that, all threads will be alive for the
> test
> when threadapply.exp calls 'thread apply detach', and they will only
> exit after the detach, which would obviate the need for the busy
> loop.
> 
> This would however probably break the previous test with the
> backtraces,
> like Simon said, because the backtrace could put the threads
> somewhere
> in the call to ptrace_barrier_wait, and it might be deeper than one
> call
> depending on the implementation.  If you can find a way to make it
> also
> work with the barriers, and make sure that the other tests in
> threadapply also work, that would allow removing the busy loops for
> all
> test.
> 
> But if that isn't possible to do for the other tests, if you just
> want
> to avoid having dangling threads, then one idea is to separate the
> detach part of the test into another test entirely, that uses the
> barrier and no busy loop, just for testing the detach case, or use
> another .c for this part of the threadapply test. Not sure if it
> would
> be acceptable to make a separate test.  But the barrier would avoid
> having to deal with the pid recycling issue.
> 

Moving the detach code to the end of thr_apply_detach simplifies the
patch significantly.  The current busy loop runs a really long time
relative to the length of the detatch tests.  So I do think that is a
very safe solution.

The ptrace_barrier_wait approach is definitely more complex and could
break the other tests as you described.  I have not implemented this
approach yet so I can say for sure what the issues may be.  The issue
is only with the detach tests so I can't see splitting the test into
two tests and then using the barrier method on the other tests that
don't have the issue of threads left running.  It is making those tests
more complex and not fixing an existing issue with those tests.  

I did move the re-attach thread code to the thr_apply_detach test and
it does seem to work. I will post it for review and discussion of the
pid recycling issue.

                          Carl