Threads [Was: Re: 64 bit euphoria]
This has proabbly been tossed around a good 50 million times on this list,
and we're no closer to a good explination of why Robert should go through
the trouble of implementing threads into Euphoria, in his own terms.
As he asked before, What could Threads solve, that isn't currently implmentable
through TCP/IP communication, Memory Sharing, and such techniques that have
been developed over the years, as ways to substitute the lack of threads.
So, I'll take a few examples of where Threads could benifit Euphoria.
First example, would be ofcourse Games.
Currently, if you need to load a bunch of graphics, your not gonna be able to
do a whole lot of other things, till all of thoes graphics are loaded up.
Even to let the user know that your loading up graphics, you have to write your
loading routine around the idea of having to display a progress bar each time
you load up a graphic into memory, so they know the game hasn't frozen on them.
Game events is another problem. Yes, Langwar is quite good, with it's ability
to proccess multiple events in a Stream like way. However, if you look at some
of the new games on the market, you'll see that 100 percent of them, use threads
in one way or another, as a way to manage multiple events, such as Enemy AI,
special events that need to occur at a certian interval, or at a certian point
in the game. That's not also considering all the networking that may be
involved.
Switching to a diffrent aspect, instead of games, moving to a Office use, so to
say, basic editors even use threads. Especially thoes that require special
rendering, such as HTML, or syntax Highlighting, such as Code editors. Right
now
in Euphoria, if you have to write a Syntax Highlighter, customly, you have to do
it when the user loads the document. And that has been prone to slowness, and
non
responsiveness of the program in the past.
Taking the fact of Writting a Custom Syntax Highligher, such as Syntax2 by Don
Phillps. The library has to load up the Source code, then parse it, searching
for
keywords, and identifying them, then applying the color codes to each part it
finds. That's just with loading the document. Then you have to render it to
screen, which proccesses the parsed information, making the appropriate
points displayed. Along with that, there's mathmatical expressions that need to
be
evaluated, such as where the user is currently scrolled to, where each word
should
be placed on the "Virtual" document based on the scroll, and the line data,
as well, as the color to be using at that said time.
All of this alone just for syntax coloring. This doesn't include the fact that
you need to process the user's input, as they enter it, looking for new
keywords,
based on what line, and what data comes before the user's new input. All of
this
contributes to slowing down the entire application in a single thread ideal.
But
should you design it for a Multi-Thread idea, you can have 1 thread proccessing
the
syntax coloring, 1 thread proccessing the rendering of the buffer to screen, and
one thread to handle all of the user's input. This can give speed to the
program
that wasn't there before, and can't be done through multi-proccesses, cause of
the fact, of the ammount of data that would need to be passed through shared
memory, or through TCP/IP, it would always create a lag. Not to mention the
fact
that it's next to impossible to pass buffer drawings in between proccesses,
since,
like memory, would always have a diffrent address.
And speaking of Multi-Proccess arch, you come to another fault that comes with
said design. And that's proper shutdown of all proccesses. Should, by any
chance
the user decides to use shared memory, in which to proccess anything, there
would
be no way for the sub-proccesses of the program to know, if the main proccess
was
killed, via kill pid on linux, or CTRL+ALT+DEL on windows. TCP/IP
communications
can help out with that, since all you have to do is detect a closing of the
socket
on the oppisite end, and you can terminate based apon that. But, there's still
things that can occur, such as crashing of the proccesses, that can't be
detected
by the main proccess, or other problems, that effectivly ends the sub-proccess,
but
leaves the main proccess running.
These are just some of the arguments, which could show that threads are indeed
better then sub-proccesses, and offer the programmer a easier way to manage his
code, without the need to write complex sub-proccess communiation, to account
for
every possibility that could happen.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
|
Not Categorized, Please Help
|
|
