RE: Threads [Was: Re: 64 bit euphoria]
Mario,
In your consideration of this issue have you reckoned on the ability
of Win32 apps to emulate threads? Some Windows libraries have a
background
processing capability that can be used to mimic a multi-threaded
process.
However, the granularity of each operation would be coarser.
Mario Steele wrote:
>
>
> 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.
API function ReadFileEx() will load in a file asynchronously (in the
background)
and then notify the user upon completion. (The progress bar is not even
needed in
this case.)
> Game events is another problem..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.
Periodic events could be (& are) detected by using API SetTimer() or
polling time()
(or something else) in the Idle section.
> 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.
When I was still learning Euphoria and programming I wrote one of the
earliest
Windows-based editors. It had (has) syntax colouring and was (is) slow
loading
documents. Perhaps this is one of the examples you have in mind when you
refer
to "slowness, and non responsiveness". If I had to write one now all
these bad
qualities etc would be gone since I now know much more now about
exploiting the
power of Windows plus better programming technique. What I am getting at
is that
my novice programming technique is not a legitmate argument against
single-threads
(or in favour of multi-threads).
You suggest that only a multi-threaded app could "give speed to the
program that
wasn't there before" because the sheer volume of xfer data "would
always create a lag".
Are you sure about this? Cooperating multiple processes are not the only
way to
share data. In the single-threaded Win32 app any data "sharing" between
emulated
threads can be as easy as "a=b".
> 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.
This argument doesn't affect the single-threaded single-process model.
> 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...
I think threads are better than sub-processes but I was hoping you'd
supply a real-life
example of this superiority that *couldn't* be satisfactorily
accomodated using the
above suggested model.
Regards,
Mike
|
Not Categorized, Please Help
|
|
