Problem with XP scheduler?
in [Win32 Kernel]
|
From: tanix on 4 Jan 2010 02:32 What are you blabbering about, you top posting, arrogant fool? :--} Enough. In article <OrYc$0NjKHA.5608(a)TK2MSFTNGP05.phx.gbl>, "David Craig" <drivers(a)noemail.noemail> wrote: >Can we confuse him with some irreverent details? For instance when a key is >struck or a mouse event occurs, whatever thread is currently running from >which ever process owns that thread will be 'tasked' to handle the >interrupt. The 'event' will then be sent to usually the Win32 subsystem for >eventual delivery to the thread & process that owns the input focus. Since >he seems so insistent upon keeping his misconceptions about Windows, we >might not want to keep it too simple. > >"Tim Roberts" <timr(a)probo.com> wrote in message >news:50c2k5d3uhi6qc3fkq71qaee77upt6q7ph(a)4ax.com... >> tanix(a)mongo.net (tanix) wrote: >>> >>>It looks totally synchronous with the mouse and keyboard events. >>> >>>From statistical standpoint, the chance is probably > 90% that a >>>task switch will occure at exactly the same time when you click >>>on something. >> >> False. >> >> Remember that user interfaces are interminably slow compared to the >> processor. Even for a lightning fast typist, there will be 3 to 5 task >> switches between keystrokes, and there will even multiple task switches >> between "mouse down" and "mouse up". >> >>>It is like task switching is some kind of a synchronous event >>>that only happens when you service the mouse click or keyboard >>>events. >> >> Well, depending on the type of mouse and keyboards, those events will >> cause >> an interrupt, which can trigger a re-evaluation of the task priorities. >> >>>What happens as a result, and especially if your box is uder a >>>heavy load, is that when you click on something, what you think >>>you clicked on is not actually what happened as far as windows >>>interpreted it. But what happened is that other event from a >>>different tast got processed. As a result things get totally >>>screwed up in terms of them happening according to your >>>expectation. >>> >>>Anybody knows the scoop on this one? >> >> Yes, the scoop is that you don't understand Windows. Task switching and >> mouse/keyboard focus are not related. It doesn't matter how many task >> switches occur in the meantime, mouse and keyboard events will be >> delivered >> to the thread that has the focus. >> -- >> Tim Roberts, timr(a)probo.com >> Providenza & Boekelheide, Inc. > > -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques.
From: Tim Roberts on 6 Jan 2010 01:12 tanix(a)mongo.net (tanix) wrote: > >The objection I have that any evaluation should not be done >in SYNCHRONOUS manner. Because the task swith may drastically >affect what user experiences. Once you click on something, >you expect that something to get active. But what happens, >is something totally different gets your mouse/keyboard event. No, it doesn't. THAT is the part that you do not understand. The mouse/keyboard event goes to the process that owns the keyboard focus, even if that process is not the one that is currently executing. Those are two separate and unrelated concepts. It doesn't MATTER which task actually has the CPU right now. I'm typing in Agent right now, and Agent has keyboard focus. All keystrokes are being delivered to Agent, even though there are dozens or hundreds of task switches going on every second. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: tanix on 6 Jan 2010 08:02 In article <48a8k5hcpulf39r6m9lh19ljolknd95138(a)4ax.com>, Tim Roberts <timr(a)probo.com> wrote: >tanix(a)mongo.net (tanix) wrote: >> >>The objection I have that any evaluation should not be done >>in SYNCHRONOUS manner. Because the task swith may drastically >>affect what user experiences. Once you click on something, >>you expect that something to get active. But what happens, >>is something totally different gets your mouse/keyboard event. > >No, it doesn't. THAT is the part that you do not understand. The >mouse/keyboard event goes to the process that owns the keyboard focus, even >if that process is not the one that is currently executing. Those are two >separate and unrelated concepts. It doesn't MATTER which task actually has >the CPU right now. > >I'm typing in Agent right now, and Agent has keyboard focus. All >keystrokes are being delivered to Agent, even though there are dozens or >hundreds of task switches going on every second. Well, I hope you realize that I am not just trying to find something to blame the windows for. What I am telling is what I saw, and MANY times over. What you are saying works just fine if you are not under heavy load, running several processes. Once you are under heavy load, these kinds of things do happen. Just a mere fact that windows redraws your desktop once you click on some GUI element, and that redraw happens EXACTLY when you click on it. It is UTTERLY synchronous. Well, what it tells ME is that the OS is totally loosing it in terms of scheduling and routing the right thing to the right process. And the most amazing thing is that it happens since the very first version of windows. And it is happening to this very day. That means there is a fundamental issue with this. I have never seen anything like this under Linux. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques.
From: Alexander Grigoriev on 6 Jan 2010 10:24 "tanix" <tanix(a)mongo.net> wrote in message news:hi21km$rra$2(a)news.eternal-september.org... > > Just a mere fact that windows redraws your desktop once you click on > some GUI element, and that redraw happens EXACTLY when you click on > it. It is UTTERLY synchronous. > > Well, what it tells ME is that the OS is totally loosing it in terms > of scheduling and routing the right thing to the right process. > And the most amazing thing is that it happens since the very first > version of windows. And it is happening to this very day. > This is what static and dynamic thread priorities are for. A foreground thread (the one that owns a foreground window) gets a priority boost. This is why it gets enough time to respond to user's actions in timely manner, even though there are background CPU-consumers. Don't tell me that you can visually detect whether redraing is done in the mouse ISR. After all, the screen image is only refreshed 60 times per second. Next thing you'll blame an OS with GUI that it's not responsive enough under heavy load (that is redrawing is noticeably delayed). Actually, you can see that in Windows sometimes, too.
From: tanix on 6 Jan 2010 12:13
In article <u22OjRujKHA.2260(a)TK2MSFTNGP04.phx.gbl>, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: > >"tanix" <tanix(a)mongo.net> wrote in message >news:hi21km$rra$2(a)news.eternal-september.org... >> >> Just a mere fact that windows redraws your desktop once you click on >> some GUI element, and that redraw happens EXACTLY when you click on >> it. It is UTTERLY synchronous. >> >> Well, what it tells ME is that the OS is totally loosing it in terms >> of scheduling and routing the right thing to the right process. >> And the most amazing thing is that it happens since the very first >> version of windows. And it is happening to this very day. >This is what static and dynamic thread priorities are for. A foreground >thread (the one that owns a foreground window) gets a priority boost. This >is why it gets enough time to respond to user's actions in timely manner, >even though there are background CPU-consumers. > >Don't tell me that you can visually detect whether redraing is done in the >mouse ISR. After all, the screen image is only refreshed 60 times per >second. Why is there a redrawing of your entire desktop to begin with? Just click on + in the explorer to expand a directory, and your desktop redraws at EXACTLY that time. Why is that? ANY clue? >Next thing you'll blame an OS with GUI that it's not responsive enough under >heavy load (that is redrawing is noticeably delayed). Don't you have anything more exciting to do in your life beyond these kinds of concoctions? -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, PHP, organized by major topics of language, tools, methods, techniques. |