RE: Threads [Was: Re: 64 bit euphoria]
Mike wrote:
> 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.)
Okay, first off with this, I wasn't refering to ReadFileEx(), or such things
as that, cause you also have to think, that ReadFileEx() loads a file into
memory, and should that file be a graphical file, still needs to be decoded
by your target graphics library. Weither that be Windows API, Exotica, Allegro,
etc, etc. And Memory Access may be faster, but it still takes time, especially
if it's a very graphical intense system, and you want certian graphics available
throughout the entire run of the program.
> Periodic events could be (& are) detected by using API SetTimer() or
> polling time()
> (or something else) in the Idle section.
Correct, on Windows, you can do this, and on Linux, you can use the time()
feature. HOWEVER. One thing to remember, is that there is no idle section
in a single thread application. I repeat, there is no idle section in a
single thread application. I say that, cause the single thread is allways
being executed, until the application itself is terminated.
The reason WHY Windows API/Win32lib/wxEuphoria/Arwen/etc/etc libraries, do
not freeze up the whole system, and actually allow other proccesses to
do their things, is cause of the PeekMessage() function, or similar.
This is the equivelent of sleep(-1) in euphoria, if the sleep() function
actually took -1 as a value. Cause in basic terms, your app is telling
windows, that your waiting for the user to do something, in order to
continue with the program. So therefore, this is why I said, some time
ago, that Euphoria already has Multi-Threading capabilities, just not
the way we'd like them to be. As in, being able to execute other code,
when the user isn't doing anything.
> 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".
As for the whole easy as "a=b" deal. This may be true, but you run into one
big detail. One VERY big detail. If it's as easy as "a=b", write a program,
that can parse the entire Win32lib file, and convert it into a token format,
where Syntax Coloring can be applied by the front end, and actually display
it. Like the Source Code Viewer in the Win32lib Demo directory. I belive
it's ex13.exw. Using any method of your choice, and see how fast, and how
far you can get with doing this method. You can use whatever method for
exchanging the data between the Main proccess, and sub-proccess, as you
would like. Then try to make it cross-platform compatable. As in, it can
run just as it sits on both windows, and linux.
> > 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.
Yes, this one I wish to retract, cause we now have a feature, we didn't have
before. But this is only useful in 2.5 of the interpreter. And I do know
for a fact, that there are people out there, that still use the 2.4
Interpreter, and even the 2.3 Interpreter.
Since now, in 2.5, we have crash_routine(), we can setup a routine, to notify
the Main proccess, that an error has occured, and the sub-proccess has died.
In the same turn, the Main proccess, can notify all the sub-proccesses that
it has died, and it can "Clear out" the sub-proccess query. So with that in
mind, I retract my previous statement about not being able to detect when a
sub-proccess, or main proccess crashes.
> > 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
> > <a
> > href="http://enchantedblade.trilake.net">http://enchantedblade.trilake.net</a>
> > 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
Real-Life example, alrighty. How many Euphoria Developers, have actually
successfully created a popular 3D Intense Multi-Player Game? And, when I
say that, I'm refering to games like Doom, Quake, EverQuest, Half-Life. And
even then, in their most Simplistic of forms, not major forms. How many
Euphoria programmers have successfully created Editor Programs, that can
match the speed of C/C++ Editors out there, in syntax highlighting speeds?
(True, Edita is very close, but it still lags on Win32lib, even on a 2.12GHz
proccessor, I know, cause I have tried it.)
And the main thing we need to remember here is, Not everyone uses Windows,
Some of us actually do use Linux (Recently Free'ed Pinguin here), and even
though we like the whole world to be on Linux, there are thoes out there,
that simply cannot handle Linux. So, if we want to do anything with them,
we have to write cross-platform programs, that can run on both Windows,
and linux, without any trouble. (As I'm currently doing)
We need to have the ability to do these kinds of things, with Euphoria,
that doesn't require us to have to re-invent the wheel to make it work,
and let alone, re-invent the wheel twice, to make it work on Windows, and
Linux.
One final note that I'd like to make, as this is actually, the perfect
real-life example, I think your looking for. How many Libraries out there
can do MD5 Encryption, Blowfish Encryption, or any kind of Encryption
algorithim on the market, without resorting to using Assembly to speed it
up?
I'm more then certian, that multiple threads can be created, to
simultaniously proccess diffrent peices of data, and update the Encrypted
data, and key, in order, without messing it up, especially if your encrypting
LARGE files.
Does Sub-Proccess mean that it will be faster? Depends on what your trying
to do. Does Multi-Threading mean it will be faster? Depends on what your
trying to do. Does Single Thread mean it will be slow? Depends on what
your trying to do. Can Euphoria stand to not have Multi-Threading support
in it? Very unlikely, even in the world today, where there are alot of
programs on the market, that heavily use Multi-Threading, to help boost
their performance. (Just look at any Office Program, any Market, or
Open Source Project Game out there)
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
|
Not Categorized, Please Help
|
|
