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

[Antonio Campos <acampos extremadura com>]

Paul Barton-Davis wrote:

> In message <390B0D32.5B0DA8F0@extremadura.com>you write:
> >Paul Barton-Davis wrote:
> >
> >> >I have tried the enclosed program over Windows 95 (with the GTK Win32
> >> >port), and Windows behaves very well indeed. No noticeable slow downs
> >> >here.
> >>
> >> AFAIK, Windows 95 uses cooperative multitasking, not preemptive
> >> multitasking, and the various components of the system that you use
> >>
> >
> >Sure?. I'm not so sure about that... I've not tried my test program on WNT,
> >W2000 (those are true preemptive, aren't they?), but I think the same result
> >would be obtained, I mean, better responses to user interactions that Linux+X.
>
> There may well be parts of WNT and W2000 that still do cooperative
> yielding, despite a preemptive kernel. Linux apps could do this
> (sched_yield() is the call), but I don't know of many that do - its
> just not necessary under any POSIX-like OS. However, if they do this,
> then sure, they will not exhibit this behaviour, but will suffer other
> consequences.
>
> >> when you are running a GTK Win32 application are written to allow each
> >> other to take control of the machine at the "right" times.
> >>
> >> Linux uses preemptive multitasking, and as Havoc pointed out, 3
> >> applications competing, rather than cooperating, for 100% of the CPU
> >> will not work in such a system.
> >>
> >
> >But you have to agree with me, that an application being able to take almost
> >all the control of the X server, IS A VERY BAD THING. It makes posible
> >malicious applications, X hangs and therefore Linux hangs, etc.
>
> No, *Linux* does not hang. The X server is just another
> application. Linux is still doing its job - scheduling 3 processes all
> of which are asking for a lot of CPU time.
>
> >I changed the scheduling policy of the X server process to SCHED_RR or
> >SCHED_FIFO and everything worked more smoothly. My application wasn't able to
> >take the control of the X server. I could move my mouse smoothly over the
> >screen, and the rest of the applications responded to my actions. But problems
> >arised, like XMMS not being able to play the music smoothly when I opaquely
> >moved big windows around the screen.
>
> Having the X server run with RT priority is just this side of insanity.
>
> >I think this is a serious inconvenience of the X system that should be
> >corrected by the XFree Team (or at least the XFree Team should know this
> >issue), because it makes Linux and easy-to-crash system.
>
> You haven't crashed Linux. You've made it harder to use with X. I
> expect that Ctrl-Alt-F1 would switch you back in a reasonable time (a
> few seconds?) to a text console, from where you could kill the
> application fairly easily.
>
> >I also don't understand that a single client process can send requests to the
> >server, but the others clients can't mix its requests between the requests of
> >the others. I don't understand why the server only cares about the process
> >that most request it.
>
> You don't seem to understand that there are all kinds of ways to cause
> denial-of-service on a POSIX operating system. You have written a
> poorly designed application, or more precisely, one that exposes a
> certain kind of weakness in the way that a POSIX OS, the X server and
> 1 or more X clients interact. I could write a different application
> that would totally screw up W95, W2000 or WNT. What conclusions should
> we draw ? If you want to write an application for any platform, you
> need to understand how its components interact, and use the right
> model in your code.

I still don't understand your position.
For me, the answer: I can screw up W95, W2000 and WNT too, is not something that
makes me happy with the current Linux+X behaviour, sincerely.

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
with gtop or kpm), all the clients process get the same CPU attention through the
Linux Kernel, but the X server is not able to schedule all the petitions equally.
(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
exactly, but I exactly say that nowadays Linux+X server is easily crasheable (for
me a system has crashed when is not able to respond in a certain delimited time to
user interaction).
And this is no good, and is a source for future trojan horses, etc...
(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...

I repeat myself, does anybody know a server+channel to talk about these X server
things, please?

Sorry for the criticism, but criticism is the source of evolution (if not, we will
be using DOS, etc...)

> JT has already demonstrated how to do that. You
> expected that you could demand 100% of the CPU from your code, and
> that it would work. We've tried to tell you that this is not the right
> way to write an X application. You can continue to fight the way that
> Linux+X works, or you understand how it works, and get excellent
> performance, excellent stability and many other benefits over the
> various Windows models.
>
> >Anybody knows a mailing-list or a newsgroup where one can complaint the Xfree
> >team about things like this?
>
> I hope you will desist from doing so.
>
> --p
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null