Re: f0dder's Fabulous Wait States.

Edgar,

I imagine that you well undersand that I sit up at night wringing my
hands and losing sleep over the opinions passed around in ALA. I have
always reduced technical matters down to testing and here the advice is
not worth listening to. I did in fact produce the 1000 thread demo of a
"shell" procedure for exactly this purpose as it very clearly
demonstrated that fashion does not beat function.

With the choice of flexible low level design that has been round since
computers started and some clunky high level routine of limited
application, I go for flexibility and efficiency every time and the
testing well proves the virtue of doing so.

Now when the major proponent colapses into preferring a HLT instruction
to the fundamental polling nauture of te entire OS and the underlying
hardware, the sum total weight of the criticism that has been flogged
for years comes into perspective, someone who wants to win an argument
at any cost when all they needed to do was learn to write reliable
software in the first place.

Now as far as functionality changes over time, I have only been writng
Windows software for 15 years straight and you can trust me on this
much, they have been breaking documented functionality with every OS
version they have ever released so there is nothing new here.

As you among others chose to atack my work on a design level, you
inherit the context that it occurs in and get the response tha the rest
get becase I have a different peer group that don't suffer the
blinkered approach to any particular programming tecnique and design
code on the basis of what it has to do, not what fashion it as to
conform to.

Now the swell of opinion in ALA over polling loop design has about the
same importance level to me as the swell of opinion about the moral
implicaions of using SPASM instead of anything else, somewhere less
than ZERO.

No-one is seriously interested in trying to replace the fundamental
polling nature of the entire Windows operating system with clunky high
level Wait state APIs because they are just not capable of doing so.
When your whole messaging system depends on a fundamental polling
design and this includes the guts or every running GUI application,
like it or not, your code runs as part of a polling loop so the point
being flogged is at best mute.

Its not as if reasonably current versions of Windows are hard to work
out if you have a tool like Proces Explorer. System idle process
followed by system interrupts, loaded processes and the rest is user
capcity.

Start and quit various applicaions and you an see the changes as they
occur and this is how you test the theories that have been expounded
here. Task Manager will tell you other things like te handle usage
count and the like and none of tis stuff is hard to use.

Come back to the fundamentals of what was the target of so many years
of abuse. A "shell" procedure is in fact a very old design that has
nothing to do with multiple synchronous applications and event timing.
It is basically stopping one application so you can run another and
when the external app has terminated, control returns back to the
calling app.

This is not the mechanics of a cluster of web servers or synchronising
the termination of a number of conditions so they all line up or any
other complex cosideration, it is still a very simple task and what I
have repeatedly rjected is te notion of "function creep". In a current
multitasking OS there is still the use of a "shell" procedure and all
you need do is understand the conditions that it must run under.

I could happily live with 1% prcesor usage for something so simple but
under test the percentage is about one 200th of one percent or less so
its fair to say that the fundamental code design is more than efficient
for the task.

I am sure you are aware that the Sleep() API is one of the Wait state
APIs that calls through two layers to the int 2Eh services in
NTOSKRNL.EXE. It correctly yields unused processor time bck to the OS
and is very easily adjusted by simply changing the millisecond delay
that it uses.

The difference is it is far more flexible that some clunky high level
wait state and you can easily adjust the loop design, add extra tests
to it, change the duration of the test depending on if the app has
focus or not and more or less anything you like.

That is why its superior technology, its put the control of the task in
the programmers hands, not endless ratting through broken or out of
date reference material trying to get some clunky high level junk to
perform a task that it may not be well suited for.

I have always been of the "Let's agree to disagree" disposition but if
someone chooses to disagree with me for years on end flaunting their
ill informed criticisms at the maximum of noise and invective, I can be
more than disagreeable in reply and in this contex you have no leverage
to prop up one of your newfound buddies in ALA.

I am sorry you have been foolish enough to take this position as I have
never had anything against you but your injury here is self inflicted.

Regards,

hutch at movsd dot com

.

Relevant Pages