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



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]