[PATCH] make strace more fair wrt many traced processes

[Denys Vlasenko]

Hi,

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.
--
vda

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 7.patch
Type: text/x-patch
Size: 4033 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20090107/2644da0e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: many_looping_threads.c
Type: text/x-csrc
Size: 692 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20090107/2644da0e/attachment-0001.bin>