[PATCH] make strace more fair wrt many traced processes

[Roland McGrath]

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

And when did this first start happening?  Was it a very long time ago?  It
might have been in the 2.6.25 kernel (from commit ee7c82da), which was only
a year ago.  But still, this is not a regression in what strace does.  How
strace has behaved in this regard has not changed in many years.

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

"Good enough" and "good enough for today" are two very different things.
If it's not a regression, then we say, "Yes, strace has issues."

I never said we should never worry about this.  What I said is that it is
not a conservative change that is appropriate for this release (or probably
the next one either).  We are maintaining a program that has been "good
enough in practice" as it is for a long time.  It is more important not to
rock the boat with any unintended consequences than to address long-standing
problems that have not been ruining anyone's life in reality.

> 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

The fact that it solicits different kernel bugs than the old version of
strace is precisely the sort of reason that makes this an irresponsible
change to make hastily.  Even if you had not observed this fallout as you
have, the mere fact that it took weeks to work out kinks means it is a
large and hairy change.  That alone makes it not a proper change to roll
into a minor bug-fix release with lots of changes that are truly minor and
don't have such risks.

Please become clear on what conservative maintenance means.
That is the job we are doing on strace.


Thanks,
Roland