[PATCH] make strace more fair wrt many traced processes

[Denys Vlasenko]

On Tue, 2009-02-10 at 18:57 -0800, Roland McGrath wrote:
> I'm not at all sure about this change.  
> Can we back it out until after the next release and think about it harder?
> 
> I'm mostly worried about unintended changes of some cases that were
> readable before now winding up with lots of <unfinished> lines swapping
> back and forth.  But more broadly, about subtle unintended consequences.
> 
> I do see the motivation, but we should be wary about perturbing this.
> Any order of processing is "kosher".  So there are various trade-offs
> to consider like the fairness one you're considering.  But more than one.

> I'm not comfortable slipping this in quietly among the bug fixes.

Anything more than four threads calling getppid() in an endless loop
and strace never finishes (on my dual CPU box).

What we shall tell users to do in this case?

"Sorry, you can't strace that program (because of strace's deficiency)"?

This does not sound good enough to me.

I was working out kinks out of this scheme for a few weeks
(it uncovered four separate kernel bugs!) and it seems to be stable
to the extent that users which strace heavily multithreaded applications
do not report more problems with it, even after they ran
their crazy testcases on it.

--
vda