Problem with XP scheduler?
in [Win32 Kernel]
|
From: Liviu on 7 Jan 2010 20:58 "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. Poorly written user-mode programs still can (and do) mess with event sequencing, for example (mis)using GetAsyncKeyState vs. GetKeyState, or recording an input event upon occurrence, but processing it later in a potentially different context (such as browsers where a mouse click may be deferred until the page is complete, and then land on a different control than originally displayed/intended). Of course, none of the above is an OS matter. But then remember that you were responding to someone whose Windows crashes "every few days" yet has no interest in fixing it and says "everything is in good shape" ;-) Liviu
From: tanix on 7 Jan 2010 23:48 In article <#OIz9YAkKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Liviu" <lab2k1(a)gmail.c0m> wrote: >"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. > >Poorly written user-mode programs still can (and do) mess with event >sequencing, for example (mis)using GetAsyncKeyState vs. GetKeyState, >or recording an input event upon occurrence, but processing it later in >a potentially different context (such as browsers where a mouse click >may be deferred until the page is complete, and then land on a different >control than originally displayed/intended). > >Of course, none of the above is an OS matter. But then remember that you >were responding to someone whose Windows crashes "every few days" yet >has no interest in fixing it and says "everything is in good shape" ;-) Well, except I am talking about the OS related operations outside of ANY running user mode program. What we are talking about here is stricly the OS issues. The problem is windows is a message based system and not a call based system. So, they inevitably have these kinds of issues because of async nature of message based architecture. We can argue about it all day long, but this is a fact of reality of what windows is. As a result, even the internal OS user mode programs, such as explorer, may exhibit this kind of behavior. In *nix the OS is designed as a call based system. So, you are pretty much guaranteed that certain sequence of events happens ininterruptingly, and that is precisely why you never see these kinds of screwups and the entire desktop refreshes that may take seconds on a desktop with all sorts of items, especially while your system is busy up the hilt. >Liviu > > > -- 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 8 Jan 2010 01:11 "tanix" <tanix(a)mongo.net> wrote in message news:hi6dfc$4at$1(a)news.eternal-september.org... > In *nix the OS is designed as a call based system. > So, you are pretty much guaranteed that certain sequence > of events happens ininterruptingly, and that is precisely why > you never see these kinds of screwups and the entire desktop > refreshes that may take seconds on a desktop with all sorts > of items, especially while your system is busy up the hilt. > You're telling that Unix is running poorly designed GUI with enormous overhead and lacks adaptive thread prioritisation, allowing background threads to compromise GUI responsiveness? If you like that better, you can change Windows settings to disable GUI prioritization. In XP, go to system properties->Advanced->Performance->Advanced->Processor scheduling, set to Background. This also will increase dispatcher time slice.
From: Tim Roberts on 8 Jan 2010 01:28 tanix(a)mongo.net (tanix) wrote: >>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? Your screen gets redrawn from the frame buffer 60 times a second the entire time the computer is on. Otherwise, your screen would go black. >Just click on + in the explorer to expand a directory, and your >desktop redraws at EXACTLY that time. No, it doesn't. First, your reflexes are not nearly good enough to detect exactly when that click happens. User interface events take a virtual eternity as far as the CPU is concerned. Second, because of screen refresh, any changes in the frame buffer won't be visible to you for 1/60 second anyway. A 3 GHz CPU can execute 180,000,000 instructions in between refreshes, and there will typically be 4 task switches in that time. >ANY clue? Apparently not. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: Leo Davidson on 8 Jan 2010 04:59
On Jan 8, 4:48 am, ta...(a)mongo.net (tanix) wrote: > The problem is windows is a message based system and not > a call based system. So, they inevitably have these kinds of issues > because of async nature of message based architecture. Messages are not inherently asynchronous. SendMessage is, semantically, the same as a synchronous remote procedure call. Some messages are posted (async, PostMessage), some are sent (sync, SendMessage) depending on what makes sense. You have very strong opinions on things and keep calling people morons when they correct you, yet you appear to not have the first clue about what you are talking about. I was hoping this thread would die out now that it's the new year. I figured it was a desperate, last-ditch attempt to make it into one of the lists, like "Dumbest Thread of 2000-2009" or something, within the few remaining days of the year, but here we still are... |