Re: Why RosAsm Breaks on a large number of symbols

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 07/07/04 

Date: Wed, 07 Jul 2004 17:23:09 GMT

Randy wrote:
> Beth wrote:
> > hutch wrote:
> > > EVERY Windows gui application as a polling loop, its
called a
> > "message loop"
> > > and it does exactly what every other polling loop does, it
> > loops until it
> > > gets a response and then does something.
> > [ snip ]
> > > Go back to the drawing board and learn how to write a
polling
> > loop, a
> > > Windows message loop is a good starting point.
> >
> > Ummm, I wouldn't call this "polling" at all; "GetMessage" is
a
> > synchronous blocking API...
> >
> > That is, it does not return until a message is available for
the
> > application to process...
>
> Don't forget, Beth, a lot of messages get sent to the
application
> that *don't* get processed by the app. It has to choose which
ones
> it wants and pass the others on through. I haven't bothered
to
> read to the end of your post, so perhaps you've covered this
fact
> somewhere, but the truth is that synchronous vs. asychronous
doesn't
> really appear in any definition of polling that I've ever
seen.
> For example, suppose I sit in a loop testing a bit in an I/O
port
> and in that same loop I call some synchronous API that may or
may
> not return for a while. Does that mean I'm no longer polling?

Ah, I was thinking in terms of _ANY_ message...not any
particular message...

Which, indeed, throws the whole idea of what's meant by
"polling" in this particular instance into question...that is,
it's NOT "polling" for messages (in general) but it is "polling"
when you're only considering a particular message...

You should have read the rest of the post...I'm actually more
concern with _blocking_ and how the scheduler works...this point
was just a "even by your own terms, calling it a 'polling loop'
is dubious enough before we go on to even consider [ rest of
post here ]"...

This was an incidental point that, in a sense, was trying to
capture that hutch's assertion that a "GetMessage" message loop
is the place to start learning what "polling" is...as it's
throwing up all these varying opinions and a case of it being
"polling" in one sense but NOT "polling" in another sense...then
this suggest strongly that this probably _ISN'T_ the place to
learn what "polling" is, in fact...it would leave you confused
when hutch is saying one thing, I'm saying another, your kind of
saying another again...blah-blah-blah...

> Polling simply describes how the application requests data.
> Specifically, it explicitly checks for the availability of
data
> under program control at periodic intervals. How those periods
> are defined (by a clock, by executing a sequence of
instructions,
> by sleeping for a while, and even by calling some function
that goes
> away until data is available) doesn't change things.

I don't think I stated that explicitly but it _should_ Hopefully
have been implicit...

No, wait, it _was_ sort of covered when I pointed out that
Win3.x used _co-operative_ multi-tasking and not pre-emptive
multi-tasking but yet Win16 and Win32 follow the exact same
style of "message loop" ("backwards compatibility" and all that
jazz ;)...but that, indeed, this doesn't effect
things...because, indeed, "co-operative" is naturally
synchronous while "pre-emptive" is naturally asynchronous...ah,
so I did kind of cover it but from a "co-operative" /
"pre-emptive" viewpoint...

And, indeed, "GetMessage" wouldn't really be qualifying under
your definition above when it comes to simply retrieving
messages (any message, not a particular one) because
"GetMessage" _blocks_ the application until it receives a
message...hence, which was what I was trying to get at in this
particular case, "GetMessage" is NOT actually checking for the
"availability of data"...if there isn't a message, then it
remains blocked...when we're talking about _any_ message then -
except for an error condition (passing invalid parameters) -
then "GetMessage" _doesn't_ return unless there's a message...

It _waits_ for the availability of data...but it is not
"checking" for it...

Mind you, then the definition of "check" comes into
question...in the context I was speaking of, to "check" would be
the application _itself_ monitoring something - such as a data
variable or flag or something - until it changes...

In the case of "GetMessage", it's a _blocking_ API so - and this
is what I mean - it's a "don't call us, we'll call you" API...it
says "_block_ this application until a message happens" rather
than "keeping checking in a loop until a condition changes"...

A subtle distinction but important in terms of the "blocking" /
"non-blocking" stuff I went on to talk about with the
scheduler...

I thought this important to comment on because, of course, the
way modern pre-emptive multi-tasking systems work, the notion of
"blocking" is integral to how they are designed to work...you
can "poll" - and may have to do so in certain contexts (e.g.
hutch is getting crashes otherwise, video cards lacks an
interrupt so the "don't call us, we'll call you" can't work when
the other person doesn't have a phone to get back in contact
with you, so to speak ;) - but this is typically a bad design
because it uses up CPU and is often unnecessary when there's a
_blocking_ equivalent...though, yes, hutch, if that method is
_crashing_ your application due to bad implementation from
Microsoft then theory has to bow to practice, in the end...if it
doesn't work any other way - it just crashes - then this is one
of those "it's actually Microsoft's problem but, regardless,
we're saddled with their crap and will have to 'work-around'
until (or more like "unless" in Microsoft's case...they don't
always bother, even when they have a "bug report" ;) they get
around to fixing it" thing...

More so if the issue is Win95 / Win98 because these are
"obselete" in Microsoft's eyes (well, they've relaxed their
"five year rule" - that an OS stops getting support after 5
years and is officially declared "obselete" and no longer
supported - on Win98 a small amount after discovering too many
people simply _weren't_ "upgrading" as they wanted...but Win95
_has_ gone the way of the dodo with that policy...and neither
Win95 or Win98 are going to have any radical changes or
"updates" to fix this particular problem, almost certainly...MS
support more interested only in suggesting "work-arounds" than
releasing some "patch"...they _want_ the thing to die and people
to "upgrade", after all ;)...

So, indeed, as I said in that post, _IF_ there's a _good reason_
why you have to "poll" then you have to "poll"..."theory" be
damned...and the fact that it just crashes to "do it properly"
on many people's machines is a good reason...which was part of
what I was suggesting that _practice_ rules, not "theory"...you
_SHOULD_ use "blocking" where possible...but if it's crashing
when you do so because Microsoft can't program then you're
forced to use a "work-around"...a "hack" to get around
that...any "shame" should not be on you for doing so, so to
speak, because the cause is _Microsoft_ not coding things
properly rather than you (or, at least, again: Having not seen
the code, I'm generalising...maybe you have made a mistake in
the code somewhere and it's not Microsoft...but I'll take your
word that it's them responsible for the crashing...not least
because this would be entirely typical of MS that the more
unbelievable thing would be Microsoft getting right rather than
the other way around ;)...

> What would change things is an asynchronous notification of
> the event. IOW, can the *application* do other processing
> (in the same thread) while waiting for the I/O to complete and
> that thread is interrupted and a separate thread of execution
runs
> when the event occurs. That's what differentiates polling
from
> non-polling I/O.

That's what I did get around to in the rest of the post...should
have read more of it, Randy...I was actually "leading in" to a
discussion about "blocking" and how the scheduler deals with
things...this wasn't the main point but an "introductory" point
to the subject at hand: "What do we mean by 'polling',
anyway?"...

On this point, "GetMessage" is a _blocking_ API...hence, the
thread does NOT do anything while waiting...it is placed onto
the scheduler's "blocked list" and only comes off when _another_
thread (part of Windows kernel) actually delivers the message to
the queue and "wakes up" the application...

It's a "don't call us, we'll call you" API...and pre-emptive
multi-tasking systems like this are designed to be more like
microwaves - making a "ping" sound when they are done so ou know
when it's "your turn" to be doing things - than being a case of
sitting there with a "watched pot" that never seems to
boil...kind of like a "relay race", perhaps, is another
analogy...you wait there to be passed the message and then start
running...rather than all the runners just running around the
track, anyway, passing the baton when they just happen to be
running passed each other...

Although, to come back to you, Randy, you suggest "while waiting
for I/O to complete"...I would just point out that it might not
necessarily be "I/O" that we're waiting for...it could be two
completely CPU-based non-I/O threads co-operating together
somehow (such as "message passing" doesn't necessarily have
anything to do with I/O...it usually does but it doesn't have to
be the case that there's any "I/O" involved...well, other than
that every application ultimately has some kind of "I/O"
somewhere - printing results onto the screen - or it tends to be
a useless program ;)...but that's a point of pedanticism...if we
make it completely generic then it's "while waiting for
something else to complete" - whatever that may be (but, yes,
the majority of the time, it's probably "I/O" directly or
indirectly of some kind ;) - and then the _actual_ important bit
here is whether it's a "don't call us, we'll call you" or a case
of the application monitoring something else in a loop (and, as
you say, is capable of doing something else)...

"GetMessage" is a _blocking_ API (actually as "Yield" is
actually a "do nothing" API in Win32 then "GetMessage" is the
main API out of only a handful that implicitly "yield" because
they are blocking)...

"PeekMessage" - which could be part of a "message loop", true
enough (but I did mention that in the posting at the time ;) -
is non-blocking so is a completely different kettle of
fish...indeed, in a "PeekMessage" based message loop, you'd
normally have to call "WaitMessage" or block on something else
or the application ends up taking up all the CPU's time: Which
is _why_, of course, "blocking" is the preferred means to do
things in such a pre-emptive multi-tasking environment as
this...because you're stealing CPU time from other applications
when using a _blocking_ API instead achieves the same thing
(better, in fact, there's sometimes the possibility of "missing"
a condition while polling, if it's too short-lived to happen
completely between two "checks"..._blocking_ also guarantees you
can't "miss" the condition...indeed, much like with interrupt
programming because, ultimately, it _is_ interrupt programming
underneath all of this, even if you can't see it or access it
directly from the application :)...

On the other hand, as I said to hutch in that post, _IF_ there's
some particular good reason why you can't use the "blocking"
version - and there appears to be, as hutch says it crashes on
particular systems (though, maybe an investigation into why and
if there's a way to presuade Win9x not to do this could be in
order, as "blocking" is the preferred method where possible ;) -
then you can't use it...indeed, I was specifically not taking
any "sides" in the little "fight" going on but just addressing
the technical concerns (because hutch made two assertions: "the
Windows message loop is the place to start learning about
polling" and that threads "yield to higher priority threads"
(when, in fact, if they were "higher priority", they'd have the
"priority" so the reverse - yielding to _lower priority_
threads - is most likely what would actually happen ;) that I
wanted to address, in case someone got the wrong ideas from it
:)...

Beth :)