OpenEuphoria

RE: Threads [Was: Re: 64 bit euphoria]

• Posted by Mike <vulcan at win.co.nz> Apr 25, 2005
• 465 views

Mario Steele wrote:
> 
> 
> posted by: Mario Steele <eumario at trilake.net>
> 
> Mike wrote:
> > A file that requires a substantial amount of contiguous decoding *time* 
> > may benefit by running in a separate thread so that the rest of the app 
> > doesn't 'hang' for a bit. But, apart from action games or an Internet 
> > browser when would this ever be a problem?
> 
> Let's see, Multimedia Applications, You don't honestly think Winamp is a
> single thread program do you?  How about Windows media player, and it's
> skinning capabilities?  Think that's a single thread system?

Those sorts of apps require a Device Driver to largely take care of the 
concurrency requirements. Writing a Device Driver in Euphoria would be 
extremely difficult but invoking one from Euphoria is not. Unless you 
think that Euphoria can be "all things to everyone" it may be best to 
limit the arguments to what is likely to be practical, though, I am not 
suggesting I wouldn't like Euphoria to suit a greater range of 
applications.

> How about the Euphoria interpreter itself?  How much of a speed boost 
> would
> it receive, if it used threaded setup for parsing files, and executing
> statements?  If a threaded arch was put into the interpreter itself, it 
> would
> be next to the speed of an Actual C Program, and offer true execution on 
> the
> fly, as most interpreters do.

If this is true then Rob, who is an expert programmer, has overlooked an 
excellent way to boost the performance of what may be the fastest 
interpreter in the world.
interpreter is based after.

> Okay, this here is totally bias.  You honestly think that code parsing, 
> and
> code rendering is a simultaneously thing.  It isn't.  It is a single 
> stream.
> Whenever an instruction is being executed, that instruction blocks all 
> other
> instructions, till it is finished.

> Even through using Win32 API, the Win32 API Can still receive events, 
> and
> such, cause that code is threaded.  But as far as Euphoria is concerned, 
> when
> interacting with said API, it can only proccess one event call at a 
> time.
> Meaning, that Euphoria doesn't proccess any Key Events (for example), 
> during
> a Paint Event, unless the User specifically Looks to see if there are 
> any
> key events to be proccessed.  Simultaneously execution means, that two
> instructions can be executed at the same time.  That is threading, 
> that's not
> single thread.  Single thread is sequential execution.
> 
> Just because it happens in a matter of less then a millasecond, doesn't 
> mean
> that it's doing the instructions simultaniously, it just means that 
> computer
> is fast enough to successfully do this in a seemingly simultaniously 
> method.

Under the heading of "Multitasking" the Win32 help document I have 
notes: 

<QUOTE>

A multitasking operating system divides the available processor time 
among the processes or threads that need it. Windows is designed for 
preemptive multitasking; it allocates a processor time slice to each 
thread it executes. The currently executing thread is suspended when its 
time slice elapses, allowing another thread to run. When the system 
switches from one thread to another, it saves the context of the 
preempted thread and restores the saved context of the next thread in 
the queue. 

The length of the time slice depends on the operating system and the 
processor. Because each time slice is small (approximately 20 
milliseconds), multiple threads appear to be executing at the same time. 
This is actually the case on multiprocessor systems, where the 
executable threads are distributed among the available processors. 
However, you must use caution when using multiple threads in an 
application, because system performance can decrease if there are too 
many threads.

<ENDQUOTE>

In other words, true simultaneous execution only occurs where there are 
two or more processors. Where there is one CPU the threading only 
appears to execute simultaneously. The background process in Edita 
mimics the latter model by setting a time slice for the (iterative) 
process. If you can assert that threads in a single-CPU are executing 
simultaneously then surely I can do the same for Edita since the basic 
principle is essentially the same.

Regards,
Mike