[PATCH] make strace more fair wrt many traced processes

[Denys Vlasenko]

On Wed, 2009-01-07 at 20:06 +0100, Denys Vlasenko wrote:
> Attached little program many_looping_threads.c
> starts N threads, and exits (terminating them all)
> as soon as they are all started.
> Each thread runs infinite loop with getuid().
> N is given and a 1st command line parameter.
> 
> Ran standalone, it finishes ok, even with large
> number of threads (500).
> 
> Currently, strace -f fails miserably starting approximately
> with 5 threads. After a few threads created, strace
> is flooded with syscall entry/exit notifications
> from these threads, and the main thread (which wants
> to create more threads) does not get a chance for its
> syscall start/stop notifications to be delivered!
> 
> This patch fixes it. Run tested.
> 
> The gist of the patch is that we don't wait(2) for the *first* process
> to stop/exit, we wait for them all (calling wait(2) in a loop, with
> WNOHANG). Only when we got all such processes, we process them and
> restart them.
> 
> This ensures that one or a few fast stopping/starting/stopping threads
> can't usurp strace's attention. Slower threads will always get a chance
> to do at least some progress.
> 
> The patch needs some comment removal and re-indentation before it can be
> applied to strace cvs, but otherwise seems to be ready.
> 
> I'd vote for subsequent patch to split trace() function into "collect
> stopped tasks" and "process collected tasks" parts, without changing
> the logic.

These changes are committed to cvs now. Yell at me if something broke.
--
vda