Re: [gtk-list] Re: X and idles => incredible slowdowns

[Jon Trowbridge <trow emccta com>]

On Tue, May 02, 2000 at 01:13:16AM +0200, Antonio Campos wrote:
> The interesting thing is that I CAN DO a VERY SIMPLE program that
> gets the X server to a very a bad state.  And that's BAD (don't you
> agree with me?).

Yes, it is bad.  But it is really *that* bad?

You are probably thinking to yourself: "Why do all these people on
gtk-list not more concerned about this huge design flaw that I've
found?"

The reason (AFAIAK) is that you've independently rediscovered
something that all of us already know: that a runaway (or rogue)
process can make our computers very unpleasant to use.

Sure, it would be nice if that weren't the case.  The question is:
what are the costs and benefits of changing this, and do the benefits
outweigh the costs?

I don't pretend to know the answer to this --- it is a difficult
question.  But I do know that lots of very clever people who know much
more about the subject than me are aware of this "problem", have been
aware of this "problem" for a long time, and (AFAIK) are satisfied
with the status quo relative to possible alternatives.

Maybe the alleged experts are wrong, and there is a clever solution to
this problem.  I know that some systems let you put per-process and
per-user limits on CPU and memory consumption.  Maybe Linux does ---
I've never investigated the question.  This might make sense for
multi-user machines, but I certainly want to be free to consume as
much of my own machine's CPU and memory as I want.

If I tell a program to grab as much of the CPU as possible, and to
place heavy demands on the X server, I don't want the system
second-guessing me.  Maybe I'm doing some very complicated real-time
scientific visualization, and I don't care if my overall X performance
is degraded.  For any "solution" to be acceptable, it shouldn't hurt
my performance in this situation.

After all, the above scenario is very similar to what your program
did.  Your code *explicitly says* to consume *all available* CPU, and
to use that CPU power to *bombard* the X server with requests.  If
this situation could arise by accident, I agree that this would be
very bad.  But it didn't arise by accident --- you spelled out very
clearly what you wanted to have happen, and the system faithfully did
it.  On a single-user workstation, to do anything else would (IMHO) be
silly.

After all, your system didn't crash (as certain other operating
systems always seem to do when confronted with heavy loads).  You just
had bad interactive performance.  You could still kill your process
--- it just took longer, and you had to deal with a jerky mouse and
bad interactive performance?  But so what?  How often is this really a
problem?  To me, that is a small price to pay for a system that does
what you tell it to do, and doesn't second-guess you all of the time.

(And, as a footnote: I think that your concerns about "rogue apps" are
somewhat misplaced.  X has been around for a long time: since I first
used X (in 1987, IIRC), I have *never* heard of such a rogue app.  And
I've never heard of a non-X "for(;;) fork();" style rogue app either.
Maybe I'm not tuned in enough, but I think that we have much more
pressing problems, and that concern about these hypothetical rogue
apps does not warrent inconveniencing thousands of people who regularly
pound on their machines and want to suck every last bit of performance
out of them...)

-JT 




-- 
GNU/Linux: Free your mind and your OS will follow.