Re: Alternative process termination notification in a GUI
- From: "hutch--" <hutch@xxxxxxxxx>
- Date: 25 Aug 2005 10:40:06 -0700
I guess we all know that Windows is an asynchronous universe but most
know that processors only ever simulate asynchronous operation and it
still breaks down to "doing one damned thing after another".
In a single binary file, you do in fact get sequential operation which
is both a blessing and a curse, depending on what you want to do. If
you want predictable sequential operation you will have no problems at
that level but start running, using or depending on any external
process and you buy into synchronisation if thats what you need.
Now it would be "nice" if the whole world worked to one unifying theory
but in fact it does not and the range of tasks is massive so the range
of solutions is equally massive. I keep being told that everything from
a very simple "shell" operation to a single outside process requires
the same solution as a cluster of web servers which I suggest is simply
not the case.
What I am rejecting in no uncertain terms is the great unifying theory
of one size fits all as it has been very easy to demonstrate that it
does not. The 1000 threads of polling loops proved in no uncertain
terms that it is a viable solution for a task of that size where the
guts of an Apache web server or the like simply does not.
The topic for this thread is another solution that fits another size
and type of task and it also runs with no additional overhead at all,
is built directly into the system and is very efficient and a lot more
flexible than the original solutions that were offered.
Now Donkey's sugestion in this task type may in fact work far better
than the previous suggestions with the MsgWaitForMultipleObjects() but
by itself I don't see that Windows messaging has suddenly become less
useful.if you can perform the task(s) you have in mind.
While I tend to see the collection of signal state API functions as
clunky high level operations, I am happy to see them used if the task
in hand justifies their particular capacity but in a world of many
sized tasks of many different types, the "one true way" approach does
not have the proof to back it up.
When all someone can do is make dire warnings about "if you do someting
much larger, a simple solution will not work", all they are telling me
is they would prefer to use a more complex solution where a simple
solution works better.
If you are writing the successor to the Apache Web server software for
a cluster then you most probably will not be using a simple solution
but then you may not be using the signal states of this OS to screw it
all together either.
The epitomy of lousy code design is to do not only more than you need
but often to do far more than you need when it acheives nothing except
code bloat and poor performance and in this much, performance can be
objectively determined and it is not a mater of opinion.
Regards,
hutch at movsd dot com
.
- Follow-Ups:
- Re: Alternative process termination notification in a GUI
- From: Alex McDonald
- Re: Alternative process termination notification in a GUI
- References:
- Alternative process termination notification in a GUI
- From: hutch--
- Re: Alternative process termination notification in a GUI
- From: f0dder
- Re: Alternative process termination notification in a GUI
- From: hutch--
- Re: Alternative process termination notification in a GUI
- From: randyhyde@xxxxxxxxxxxxx
- Re: Alternative process termination notification in a GUI
- From: hutch--
- Re: Alternative process termination notification in a GUI
- From: Donkey
- Re: Alternative process termination notification in a GUI
- From: hutch--
- Re: Alternative process termination notification in a GUI
- From: Alex McDonald
- Alternative process termination notification in a GUI
- Prev by Date: Re: Technical superiority of polling loops
- Next by Date: Re: The Value of a CS Degree
- Previous by thread: Re: Alternative process termination notification in a GUI
- Next by thread: Re: Alternative process termination notification in a GUI
- Index(es):
Relevant Pages
|