Re: The revelation of St. f0dder the Divine

Alex McDonald wrote:
> Frank Kotler wrote:
> > Beth wrote:
> >> You've shown before that you don't entirely grasp how the
"priority"
> >> scheduling scheme in Windows works, hutch...and you're doing it
again,
> >> it seems...
> >
> > It's my understanding that Hutch knows perfectly well that a polling
> > loop is a very "inconsiderate" thing to do in a multi-tasking OS.
But
> > the blocking alternative crashes on certain hardware/version
> > combinations. (I guess there's some question if this is true or not,
but
> > that's why Hutch does it that way... I understand)
>
> It seems a little suspect; there would certainly be several other
> problems in other applications if wait functions didn't work as
> advertised on those hardware and OS versions. Sleep would be one of
the
> victims.

Yes...a more succinct version of what I was also finding "highly
suspect" in my reply to Frank too...

If "blocking" were not working, then it, indeed, wouldn't simply be a
case of "oh dear, we have to use polling then...what a shame!"...and
that's it...

The consequences to a non-functional "blocking" mechanism...in a
multi-tasking OS, where this is _FOUNDATIONAL_ and _FUNDAMENTAL_ to the
entire system's operation?

As Alex says, hutch use of "sleep" shouldn't, therefore, work...it's a
_BLOCKING_ API...

Further, though this may not be visible, Windows itself almost
doubtedlessly uses the _SAME SYSTEM_ internally...inside all those DLL
files...inside the kernel...part and parcel of the scheduler...

I suppose - at a stretch - this could be a "highly selective" bug that
decides only to effect the sole thing that, lo and behold, hutch wants
to do...yet, leaves all other things perfectly alone and fully
operational, so that it otherwise runs perfectly well...

But the likelihood of this?

Put it this way...I'm NOT accepting hutch's word on this "selective bug"
until he _DEMONSTRATES_ conclusively - to full scientific standards of
evidence - that he's not trying to bull*** his way out of this...

> > The polling loop isn't getting 100% CPU time because there's a
"sleep"
> > in the loop. (again, some controversy whether it should be "sleep 0"
or
> > "sleep 1", I guess...)

[ Yeah...and "Sleep" is a blocking API...so, how is it "blocking doesn't
work", yet hutch makes use of a blocking mechanism? ]

> Certainly not a Sleep(0), as if the thread was at a higher priority
than
> the thread on which it's waiting, the subordinate thread would not get
> serviced at all. The Windows scheduler does try to avoid the problem
of
> priority starvation by eventually giving all ready threads a
timeslice,
> regardless of their priority; but it may take several seconds for it
to
> do so. It would run very slowly indeed.

Nice to hear someone who realises the way the scheduler works is
actually an important consideration...rather than "oh, this worked with
DOS batch files" and thinks concurrency is all a "trivial" /
"irrelevent" consideration...

> > If the "blocking" alternative fails because of a bug, what would
*you* do?
>
> Find a better OS, because it would be useless for other reasons if
this
> were a problem.

Exactly...if "blocking" were "non-functioning" as hutch seems to be
claiming, then how on Earth it manages to even boot up and run long
enough to even allow him the opportunity to run his program to see if it
works or not...goodness knows...

The entire system _USES_ this mechanism all over the place...concurrency
is a "somewhat delicate balance" in that if the kernel were "doing it
wrong" in any serious kind of way...then this wouldn't only have "mild"
and "ignorable" consequences...it would trigger either "deadlock" or
"lock up" or going totally AWOL or something similarly "spectacular"...

> I would certainly expect to see KB articles in MSDN
> about it, and I can't find any hits on AMD that are relevant.

Ah...well...nothing about it on MSDN or AMD's site, you say?

I think that has got to be pretty much "case closed", folks...it was
impossible enough to believe that "blocking doesn't work" in the first
place...but that it "doesn't work" and Microsoft don't even mention it
anywhere? Oh, come on...

See my other post for one of MANY possible alternatives to hutch's
problem which doesn't require "polling"...basically, just use "IPC" and
"synchronisation primitives"...this is, after all, what these darn
things were invented to do!!

Just create a system-wide "mutex"..."child" grabs it (it is created in a
"grabbed" state ;)..."parent" blocks on trying to grab it too...the
"grab" of the "mutex" by the "parent" won't succeed - won't unblock -
until the "child" leaves go first (which it only does when it
terminates)...

There you have it...it uses "blocking", so it won't take up CPU
time...and it'll correctly "unblock" the instant the "child" leaves
go...

Well...this at least covers how to "block on child process
termination"...getting the actual "exit code" from the "child" can be
"negotiated" in many ways...you can work that out yourself :)...

Although, Alex's got a point about the "better OS"...Linux has a rich
set of IPC mechanisms (including "shared memory" directly...no need to
piss around with "file mapping" - to "fake up" shared memory through a
mechanism actually designed for something entirely different- as Windows
makes you do)...and this stuff is all pretty fundamental "syscall" stuff
too...

Remember, UNIX (except possibly for its first few incarnations before it
was even written in C, before the "pedants" descend ;) always was a
multi-tasking, multi-user system...this is fundamentally in the design
"from the ground up"...

Whereas, Win32 has to maintain "source level compatibility" with Win16,
which was "co-operative multi-tasking", not pre-emptive...had a "one
shared address space" memory model rather than true process
separation...oh, and used to run on top of single-tasking DOS...

In other words, UNIX was _DESIGNED_ for this kind of thing from the
ground up...and its support is rich, fundamental and well-designed...

While Windows was some "graphics" bolted onto DOS, which had some
"co-operative multi-tasking" bolted onto that, which they then undid
that and bolted on "pre-emptive" instead (though for "backwards
compatibility", it had to maintain redundent parts introduced by
previous models, which no longer apply)...and bolted this on...and
painted over the crack over there...and patched over that problem...and
then finally got around to thinking of the "security issues" of it all
20 years too late, when there's bugger all they could do to make the
radical, fundamental changes that are actually needed to make it even
marginally "safe" for use...blah-blah-blah...

Are we getting the bigger picture here?

Yeah, exactly...

Or, put another way: In Linux, what you need is system call #7
("sys_waitpid")...that's it...end of story...

You'll note it's the 7th system call Linus ever implemented for
Linux...it was _NOT_ an
"afterthought" that was "bolted on" in Linux's design...you can be sure
of that...

Beth :)


.