Re: Why RosAsm Breaks on a large number of symbols
From: hutch-- (hutch_at_movsd.com)
Date: 07/08/04
- Next message: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
- Previous message: T.M. Sommers: "Re: Why RosAsm Breaks on a large number of symbols"
- In reply to: Beth: "Re: Why RosAsm Breaks on a large number of symbols"
- Next in thread: luvr: "Re: Why RosAsm Breaks on a large number of symbols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Jul 2004 19:34:33 -0700
Beth,
Your post is a large one to respond to comprehensively so I will spot
a few things in it. Polling is a process of waiting for and event to
happen and then responding to it. It has never taken into
consideration what the event was as it can be a variety of things like
waiting for an external piece of hardware to respond to waiting for
the disk IO system to finish writing a file to disk or any other event
that takes time.
In this context, a Windows message loop is no different, it is a loop
that calls the GetMessage() API, waits for it to return and responds
to the return value. Now there is no secret that the OS does not send
any message to the app while there are none in the message que so the
loop sits suspended until another message is sent to it. What you are
describing here is the difference in "event type", not the method of
polling for the event.
Now with the issue that has been raised for years by a certain party
about running an external executable file, I chose a similar design
some years ago when I needed to run seperate EXE files and I went for
a standard polling loop that checked the return value of the child
process and exits the loop when the right return value occurs. I went
for this method because of its reliability and access to how it
actually works, the low level versus the high level approach.
When I wrote the last install for the MASM32 project, the old version
interferred with the child processes because it was using too much
processor time so I modified the algo by adding an API that yielded
the time slice and this brought its processor usage when running an
external process down to about zero. (benchmarked)
Now where the problem has been with the years of a certain party
harping on about how an alternative design must be used is the method
of coercion that has been tried over and over again when the
benchmarking does not support the assertions being made. When the
"shell" procedure runs an external process with a higher priority, it
was slightly faster than the suggested method (benchmarked) so it is
not less efficient than the method that has been sold as technically
superior to it.
Behind the years of whinging and attempted coercion is the assumption
that Windows API functions are consistent where from 14 years of
writing this stuff, they are badly designed, inconsistent and vary
from version to version, the last set of blunders was whoever rewrote
all of the API functions that have unicode alternatives as it seems
they did not properly understand the original functionality and broke
a reasonable amount of code doing it.
I have had to rewrite enough code that was built to the documented
specifications in the past to be familiar with the problem. Over the
life of this nonsense I have heard a multitude of arguments about
process priority, multithreading designs and the like yet a procedure
aimed at a historical DOS functionality never adressed such
considerations, it was designed to run a seperate EXE file in the same
way as you did in DOS years ago in a synchronous manner.
No serious multithreading application tries to use this style of
procedure, like everyone else, they roll their own on the basis of
need and it does take a lot more understanding than parrotting the
virtues of an API call like WaitForSingleObject(). In anything that
actually matters, you use a controlling app that suspends the thread
while it is not being used and resumes it when it is required again.
Within the boundaries of priority which varies a lot from OS version
to os version, again any serious applcation uses a controling app that
keeps track of what is runnung under what priority and for what
reason.
The repearted raising of this issue has never been a technical one, it
has always been an influence peddling matter from someone who has a
bad track record of parrotting incorrect technical data at learner
programmers with purile excess for years on end. For people like
myself and many others, the viral technology "yadda yadda" behind it
does not interest me and I will not take notice of someone who has
kept hammering their mistakes for years on end.
There is always an alternative for a talking head who does not like
the procedure, they can write their own assembler library and
distribute it and find all of the joys of doing so. They can put all
of their design advantages in one package and become the leading
assembler guru they aspire to be.
Just as an aside, I put a lot of work into the last version of MASM32
and had a lot of help testing it to make sure it was reliable and
somewhere along the line, when I rewrote the binary search algo, I
PHUKD up the search near the beginning of the algo where it would not
find a pattern within the first few bytes. If I remember correctly, I
twiddled the algo to make sure you could not set a starting point that
would make the pattern read past the end of the source which worked
but wrecked the other end of it.
Fortunately one of the forum members found the bug and I rewrote it so
it did both ends corectly.
Regards,
hutch at movsd dot com
- Next message: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
- Previous message: T.M. Sommers: "Re: Why RosAsm Breaks on a large number of symbols"
- In reply to: Beth: "Re: Why RosAsm Breaks on a large number of symbols"
- Next in thread: luvr: "Re: Why RosAsm Breaks on a large number of symbols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
