Re: Threads [Was: Re: 64 bit euphoria]
One time I wanted to make a web server, so I looked at some other
ones, and some tutorials. I saw several ways to use winsock. I started
with the blocking methods just because they seemed easiest. Then after
only one connection at a time was possible, I started to think. At the
time I was taking a C++ class at school so most the tutorials I looked
at where C. I had been using euphoria for years by then, and wanted to
do a euphoria web server. So I started to port a threaded web server
tutorial to euphoria. And the threads did work, for a minute. Anytime
I printed to the screen, it crashed, and randomly all the time. Then I
read somewhere that euphoria wasn't thread-safe, and I was
heart-broken. The language that was my favorite, and had used for
years, and wrote lots of stuff in was not able to do something that I
really wanted to do.
So I gave up and wrote it in C. Then later I came back to it, and
found the asyncselect command in winsock, and made it with win32lib in
euphoria, and was kinda disappointed at the speed, but happy it was
possible.
So while everything may be possible in euphoria without threads, it
kinda hurts that there not there when you want them. It hurts speed,
algorithm choices, and even the user base, which I think would be
bigger otherwise.
Dan
On 4/23/05, Mike <vulcan at win.co.nz> wrote:
>
> 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 eac=
h
> > 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 Enem=
y
> > AI,
> > special events that need to occur at a certian interval, or at a certia=
n
> > point
> > in the game. That's not also considering all the networking that may b=
e
> > 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 tha=
t
> > 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 mentio=
n
> > 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 b=
e
> > 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
|
|
