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

[Valdis Kletnieks vt edu]

On Tue, 02 May 2000 01:02:50 +0200, Antonio Campos <acampos@extremadura.com>  said:
> I don't understand yet, why the X server (or the window manager) tends to
> acknowledge only one client process, and it's not able to respond to the rest of
> the user interface, because theorically (and in the practice, I have tested it

Well.. let's look at it from the OTHER end.  The X server is, in
this case, handling requests from (say) 2 programs - your rogue
program and the window manager.

The window manager is being nice, and issuing requests when it
feels the need - perhaps 10/second tops.  Your rogue program has
been specifically told to soak *all* available CPU and use it to
issue requests.  Even on my 332mz PowerPC system, a process can
issue 5,000+ syscalls/second.

Are you surprised that when one process issues 500x as many
calls as the other, that it uses up 500x as much of the X server's
capacity? Of course, things *will* bog down if the program issues
a lot of calls (such as 'move a window') that are cheap to issue
but expensive for the X server to implement - if the X server
is busy displaying a 200x200 window 300 times a second, of COURSE
it will be just a bit slow to respond...

Unfortunately, there isn't any low-overhead way for the X server
to say "X client ABC is only allowed to chew 60% of the capacity",
because the actual load generated will depend on a lot of things,
such as the type of X call (move-window is a LOT more expensive
than XAllocColor(), for instance, especially for very large windows),
the exact parameters (8-bit versus 24-bit visuals, etc), and a whole
slew of other details.

> (Maybe something with the X servers buffers?, maybe the X server should have a
> thread to attend to the the mouse/keyboard/user interface in general for being
> able to kill the X server when it gets to an unstable situation?). I don't know

Well, unless you started the X server with the -T flag, it will
usually fold up and die *real* fast if you give it the 3-fingered
salute of control-alt-backspace.  I've been doing X since X10.4, and
the *only* time the X server ignored a 3-finger salute were if it
was started with -T, or if it was completely wedged in an infinite loop.

> (I know, maybe the kernel should have a mechanism to become to a determined state
> where the user can kill any ofending application: for me this should be a right
> OS).
> The fact that POSIX/UNIX* in general doesn't have this, doesn't mean that is the
> right thing...

The DOD Orange Book calls this a "Trusted Path".  I know that AIX 4
implements it, and other Unixoids may as well.  Unfortunately, in the
context of X, "getting to a determined state" is non-trivial - you
basically have to blow away the X server to do so (as you have noted,
if the X server is hosed, you can't kill it from an xterm.. ;)

And that, my friends, is why the RS6000 in my office has a nice
monitor on it, and an actual VT220 terminal hanging off the serial
port - its sole purpose in life is so I can have a live getty running
where I can login and get a 'kill -9' or 'shutdown -r' in when I manage
to hose up the system. ;)

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech