1. 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...
2. 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
>
>
>
>
>
3. Re: Threads [Was: Re: 64 bit euphoria]
On Sun, 24 Apr 2005 06:25:00 -0700, Mario Steele
<guest at RapidEuphoria.com> wrote:
>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.)
If you still have Edita installed, and have a spare moment, can you
post some figures for me, along with the name of the presumably Linux
editor you are comparing it against?
Thanks,
Pete
4. Re: Threads [Was: Re: 64 bit euphoria]
Hey Pete,
Pete Lomax wrote:
> If you still have Edita installed, and have a spare moment, can you
> post some figures for me, along with the name of the presumably Linux
> editor you are comparing it against?
Guess you kinda missed the whole "(Recently Free'ed Pinguin here)" part in the
following paragraph. Unfortunatly, that means, I no longer have a Windows
partion on the hard drive. But eh, it's okay. From what I can remember,
the closest figures I can give you on loading Win32lib in Edita, was around
3-4 seconds to fully parse it, and display the first "virtual" page of the
Win32lib Source code. Agreed, not much of a delay, but Crimson Editor on
Windows, can load up the entire Win32lib, and display, in less then, to about
a second.
Unfortunatly, the only Syntax Editor that has been developed for Linux/Windows,
aside from Modifications to EE, Matt Lewis ported the Syntax 2 control in wxIDE,
and I have not yet tested how long it takes wxIDE to parse it, and display it,
due to the fact that wxIDE is still unstable in most parts.
I wish I could help ya out more, but tis all I can give ya. Sorry.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
5. Re: Threads [Was: Re: 64 bit euphoria]
On Sun, 24 Apr 2005 19:30:47 -0700, Mario Steele
<guest at RapidEuphoria.com> wrote:
>Pete Lomax wrote:
>> If you still have Edita installed, and have a spare moment, can you
>> post some figures for me, along with the name of the presumably Linux
>> editor you are comparing it against?
>
>Guess you kinda missed the whole "(Recently Free'ed Pinguin here)" part in the
I thought you might be running it on Wine, but I think that was Pete E
(and he did suggest a few bugfixes to make it run correctly which I
may not have uploaded yet)
>following paragraph. Unfortunatly, that means, I no longer have a Windows
>partion on the hard drive. But eh, it's okay. From what I can remember,
>the closest figures I can give you on loading Win32lib in Edita, was around
>3-4 seconds to fully parse it, and display the first "virtual" page of the
>Win32lib Source code. Agreed, not much of a delay, but Crimson Editor on
>Windows, can load up the entire Win32lib, and display, in less then, to about
>a second.
I trust you understand I feel obliged to correct you. You must have a
very slow box indeed if it takes 3-4 seconds. (You sure you meant
2.12GHz and not 2.12MHz?) I have just downloaded the latest version of
Crimson Editor, just to make sure it has not recently been drastically
improved, and it still takes at least six times longer than Edita to
load win32lib, and that is being generous (OTOH you must have a fairly
decent box if Crimson manages that in under a second). According to my
timings, CE is only a fraction faster than _MEditor_, which may be the
source of confusion here.
Regards,
Pete
6. Re: Threads [Was: Re: 64 bit euphoria]
On Mon, 25 Apr 2005 21:09:28 +0000, Mike <vulcan at win.co.nz> wrote:
>Mario Steele wrote:
>> 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.
The actual start/end time would be no better, but it would appear
faster; much like 2.4 does to me over 2.5 I guess
)
>
>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.
It is also true to say that a single thread model will, if programmed
sensibly (and possibly duplicating some of the thread-like features
the OS provides) /always/ run faster than a multi-thread program.
However I think Mario is missing the point about which is /easier/.
That is the real question, at the moment I only have Edita on which to
base any opinion, at all.
OK: GENERAL QUESTION TO ALL:
If there was something you wanted threads for, what would it look like
in your ideal snippet of Euphoria code?
Regards,
Pete
7. Re: Threads [Was: Re: 64 bit euphoria]
- Posted by Patrick Barnes <mrtrick at gmail.com>
Apr 26, 2005
-
Last edited Apr 27, 2005
On 4/26/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
> OK: GENERAL QUESTION TO ALL:
>
> If there was something you wanted threads for, what would it look like
> in your ideal snippet of Euphoria code?
The thing that a true threaded model can offer that a simulated model
can NEVER offer is preemptive multitasking (as opposed to cooperative)
Ideally, a 'thread' would be similar to a procedure or function
declaration. A few other things like semaphore (wait and signal) and
mutex support would be nice too.
An example:
integer mutex_job=20
thread long_processing_job( sequence data )
--Do lots of processing on data, this takes a long time.
...
mutex_job += 1
end thread
...lots of windows code.
procedure onButtonClick(id, event, params)
if mutex_job then
mutex_job = 0
long_processing_job(data)
end if
end procedure
procedure onTimer(id, event, params)
if mutex_job then
setText(text, "complete!")
end if
end procedure
...other windows code
For instance, here is a function(originally) called
long_processing_job. While iterative, there's no easy way to insert
doEvents(0) calls, as at one level it's called too often, and at the
next level it may not be called enough.
This code snippet allows the program to remain responsive to the user,
while the processing is being done.
A more mature thread implementation might support one thread
triggering a windows API event in the first, rather than being
polling.
--
MrTrick
----------
8. Re: Threads [Was: Re: 64 bit euphoria]
Patrick Barnes wrote:
>
> On 4/26/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
> > OK: GENERAL QUESTION TO ALL:
> >
> > If there was something you wanted threads for, what would it look like
> > in your ideal snippet of Euphoria code?
>
> Ideally, a 'thread' would be similar to a procedure or function
> declaration. A few other things like semaphore (wait and signal) and
> mutex support would be nice too.
How about something like... :
sequence data
integer mutex_lock, print_data_id, highest_id
mutex_lock = 0
-- data gets set...
procedure print_data()
mutex_lock += 1
for i=1 to length(data) do
print data[1]
end for
mutex_lock -= 1
end procedure
print_data_id = routine_id("print_data")
function highest()
integer max
mutex_lock -= 1
for i=1 to length(data) do
if data[i]> max then
max = i
end if
end for
return data[max]
mutex_lock -= 1
end function
highest_id = routine_id("highest")
call_thread_proc(print_data_id)
call_thread_func(highest_id)
wait_for(mutex_lock = 0)
and use procedures and functions as threads to keep down the amount of new
syntax rules we'd have to add. However, I VERY rarely use threads so I don't know
the feasibility of this.
9. Re: Threads [Was: Re: 64 bit euphoria]
On Wed, 27 Apr 2005 07:17:39 +1000, Patrick Barnes <mrtrick at gmail.com>
wrote:
>
>On 4/26/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
>> OK: GENERAL QUESTION TO ALL:
>>
>> If there was something you wanted threads for, what would it look like
>> in your ideal snippet of Euphoria code?
>
>The thing that a true threaded model can offer that a simulated model
>can NEVER offer is preemptive multitasking (as opposed to cooperative)
Isn't that a function of the OS rather than an individual application?
>
>Ideally, a 'thread' would be similar to a procedure or function
>declaration.
OK, I would argue strongly against a function, which implies the
inititiator/initiating thread has to wait for a result, which negates
any parallelism. I can also imagine there is a routine which you might
want to make a thread in some cases, but also perform immediately, so
I'd stick with procedure.
I would also, from your post, suggest that something like
procedure onButtonClick(id, event, params)
fork(routine_id("long_processing_job"),{})
end procedure
might be much more descriptive of what was actually happening.
> A few other things like semaphore (wait and signal) and
>mutex support would be nice too.
And how you might they look? lockSemaphore(..)/releaseSemaphore(..)?
Assume that RC creates Euphoria/include/threads.e which provides the
basic wrappers around machine_func/proc, c_func/proc, or similar.
<snip>
>For instance, here is a function(originally) called
>long_processing_job. While iterative, there's no easy way to insert
>doEvents(0) calls, as at one level it's called too often, and at the
>next level it may not be called enough.
Can you explain what you mean there? In what cases would it be called
too often, and why, and in what cases would it not be called enough,
and why?
>
>A more mature thread implementation might support one thread
>triggering a windows API event in the first, rather than being
>polling.
Well, I would hope that only one thread owns a control, and it is that
thread which handles windows messages, so I don't understand the
sentiment there one bit. The message queue is thread agnostic.
Regards,
Pete
10. Re: Threads [Was: Re: 64 bit euphoria]
On 4/27/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
>
> On Wed, 27 Apr 2005 07:17:39 +1000, Patrick Barnes <mrtrick at gmail.com>
> wrote:
>
> >
> >On 4/26/05, Pete Lomax <petelomax at blueyonder.co.uk> wrote:
> >> OK: GENERAL QUESTION TO ALL:
> >>
> >> If there was something you wanted threads for, what would it look like
> >> in your ideal snippet of Euphoria code?
> >
> >The thing that a true threaded model can offer that a simulated model
> >can NEVER offer is preemptive multitasking (as opposed to cooperative)
> Isn't that a function of the OS rather than an individual application?
> >
> >Ideally, a 'thread' would be similar to a procedure or function
> >declaration.
> OK, I would argue strongly against a function, which implies the
> inititiator/initiating thread has to wait for a result, which negates
> any parallelism. I can also imagine there is a routine which you might
> want to make a thread in some cases, but also perform immediately, so
> I'd stick with procedure.
I agree there, a function implies something gets returned.
>
> I would also, from your post, suggest that something like
> }}}
<eucode>
> procedure onButtonClick(id, event, params)
> fork(routine_id("long_processing_job"),{})
> end procedure
> </eucode>
{{{
> might be much more descriptive of what was actually happening.
>
> > A few other things like semaphore (wait and signal) and
> >mutex support would be nice too.
> And how you might they look? lockSemaphore(..)/releaseSemaphore(..)?
> Assume that RC creates Euphoria/include/threads.e which provides the
> basic wrappers around machine_func/proc, c_func/proc, or similar.
>
> <snip>
> >For instance, here is a function(originally) called
> >long_processing_job. While iterative, there's no easy way to insert
> >doEvents(0) calls, as at one level it's called too often, and at the
> >next level it may not be called enough.
> Can you explain what you mean there? In what cases would it be called
> too often, and why, and in what cases would it not be called enough,
> and why?
Well mabey
for doc = 1 to length(documents_to_parse) do
--doEvents won't get called but once each document
for character = 1 to length(documents_to_parse[doc]) do
--doEvents would get called way too offten, for each character,
majorly slowing down the parsing
end for
end for
>
> >
> >A more mature thread implementation might support one thread
> >triggering a windows API event in the first, rather than being
> >polling.
> Well, I would hope that only one thread owns a control, and it is that
> thread which handles windows messages, so I don't understand the
> sentiment there one bit. The message queue is thread agnostic.
Well, I think you can send windows messages to any window you want,
for signaling things. But the windows messaging API is either polling,
or blocking, so using the messaging to avoid polling is not really
possible, unless you like the blocking better.
Dan
>
> Regards,
> Pete
>
>
>
>
>
11. Re: Threads [Was: Re: 64 bit euphoria]
- Posted by Mario Steele <eumario at trilake.net>
Apr 27, 2005
-
Last edited Apr 28, 2005
codepilot Gmail Account wrote:
<large snip>
> Well mabey
> }}}
<eucode>
> for doc = 1 to length(documents_to_parse) do
> --doEvents won't get called but once each document
> for character = 1 to length(documents_to_parse[doc]) do
> --doEvents would get called way too offten, for each character,
> majorly slowing down the parsing
> end for
> end for
> </eucode>
{{{
Okay, this is why I hate being right. See, in a Single Threaded enviroment,
YES, this would be correct, calling doEvents() in the doc loop, would be
called to little, doEvents() in the character loop, would be to much. BUT,
when you fork (Or whatever Rob decides), the document loop off into it's own
thread, it will operate SEPERATELY from the Main Thread, leaving the Main
Thread to still be able to receive the Events from the window, without being
stopped by the for loop. And therefore, it would eliminate the need to have
the doEvents() function in either of the loops.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
12. Re: Threads [Was: Re: 64 bit euphoria]
On 4/27/05, Mario Steele <guest at rapideuphoria.com> wrote:
>
> posted by: Mario Steele <eumario at trilake.net>
>
> codepilot Gmail Account wrote:
> <large snip>
> > Well mabey
> > }}}
<eucode>
> > for doc = 1 to length(documents_to_parse) do
> > --doEvents won't get called but once each document
> > for character = 1 to length(documents_to_parse[doc]) do
> > --doEvents would get called way too offten, for each character,
> > majorly slowing down the parsing
> > end for
> > end for
> > </eucode>
{{{
>
> Okay, this is why I hate being right. See, in a Single Threaded envirome=
nt,
> YES, this would be correct, calling doEvents() in the doc loop, would be
> called to little, doEvents() in the character loop, would be to much. BU=
T,
> when you fork (Or whatever Rob decides), the document loop off into it's =
own
> thread, it will operate SEPERATELY from the Main Thread, leaving the Main
> Thread to still be able to receive the Events from the window, without be=
ing
> stopped by the for loop. And therefore, it would eliminate the need to h=
ave
> the doEvents() function in either of the loops.
>
All celebrate no more doEvents!!
Dan
> Mario Steele
> http://enchantedblade.trilake.net
> Attaining World Dominiation, one byte at a time...
>
>
>
>
>
13. Re: Threads [Was: Re: 64 bit euphoria]
<snip much talk about threads>
First let me say that I really don't think that Euphoria needs threads. I don't
believe that the language needs the extra complication.
Any program that needs simulated threads instead of multiple processes can make
an event loop and set up either round-robin or timer callbacks.
> codepilot Gmail Account wrote:
> <large snip>
> > Well mabey
> >
> > for doc = 1 to length(documents_to_parse) do
> > --doEvents won't get called but once each document
> > for character = 1 to length(documents_to_parse[doc]) do
> > --doEvents would get called way too offten, for each character,
> > majorly slowing down the parsing
> > end for
> > end for
> >
>
I'm not sure what doEvents does, but I wouldn't do it this way.
Write your parser so that it operates on say 10 words at a time (or whatever is
a convenient size of work in a timeslice without slowing things down) and then
return (or do_events) at the end of that amount of work. When all the work is
done set a flag and don't do anymore work!
But if euphoria had threads, I would implement it like this:
start_thread(routine_id(new_thread)) -- Start a new thread procedure
Tlock() -- Called by threads in order to pause all other threads while accessing
shared/global variables
Tunlock() -- Unpause threads
-- I don't know enough about semaphors and messaging yet. Could probably be
done with a combination of Tlock(), Tunlock() and a global variable(s).
end_thread() -- Called by thread when its work is done; removes it from the
queue
kill_thread(routine_id(old_thread)) -- used by the main process to remove a
thread that doesn't end itself
I think that this could be written in a library that simulates the threads (like
Langwar) instead of directly in the language. And of course you wouldn't have to
worry about orphaned threads if your main process died.
=====================================
Too many freaks, not enough circuses.
j.
14. Re: Threads [Was: Re: 64 bit euphoria]
Jason Gade wrote:
>
> <snip much talk about threads>
>
> First let me say that I really don't think that Euphoria needs threads. I
> don't believe
> that the language needs the extra complication.
>
> Any program that needs simulated threads instead of multiple processes can
> make an
> event loop and set up either round-robin or timer callbacks.
>
The real argument for threads, IMHO, is that the current thinking is that
we're at a virtual dead end as far as processor performance goes, and the
future is in multi-cored machines, which a single thread can't take
advantage of. It's perhaps not Euphoria's most common use, but for those
of us who do calculations or simulations in Euphoria, this could be really
important. Multiple processes are an option, but may not be the easiest
or best way to implement a given algorithm. Not to mention the background
processing that a game might be doing.
And while processes are cheaper than threads in the Win32 realm, it's not
so in the *nix universe.
Matt Lewis
15. Re: Threads [Was: Re: 64 bit euphoria]
Matt Lewis wrote:
>
> Jason Gade wrote:
> >
> > <snip much talk about threads>
> >
> > First let me say that I really don't think that Euphoria needs threads. I
> > don't believe
> > that the language needs the extra complication.
> >
> > Any program that needs simulated threads instead of multiple processes can
> > make an
> > event loop and set up either round-robin or timer callbacks.
> >
>
> The real argument for threads, IMHO, is that the current thinking is that
> we're at a virtual dead end as far as processor performance goes, and the
> future is in multi-cored machines, which a single thread can't take
> advantage of. It's perhaps not Euphoria's most common use, but for those
> of us who do calculations or simulations in Euphoria, this could be really
> important. Multiple processes are an option, but may not be the easiest
> or best way to implement a given algorithm. Not to mention the background
> processing that a game might be doing.
>
> And while processes are cheaper than threads in the Win32 realm, it's not
> so in the *nix universe.
>
> Matt Lewis
>
Aren't threads lightweight processes by definition? I think that threads are
"cheaper" than processes in any context.
But I think you are right in that processes are cheaper in win32 than in *nix.
But *nix has a longer history of multi-processing (background processes) than in
threads.
I think for games, the simulated approach would still probably be best. But I
do understand that scientific simulation usually uses threads. I certainly don't
know much about it, though.
Are there enough people doing complex simulation in Euphoria to make it
worthwhile? Are there better tools than Euphoria for the job?
I'm not really against it as long as it is kept simple; I just see little need
for it by the majority of users. And as I said in another post, Euphoria has
some things that are more important to implement or fix first.
=====================================
Too many freaks, not enough circuses.
j.
16. Re: Threads [Was: Re: 64 bit euphoria]
Way back when I made my own eueu, it was simulating multithreading. It
would make multiple instances of the local variables, and make the
globals global. It would call do_instuction a few times, then
switch_instance, and do_instruction some more. If threading was
simulated at the interpreter level, like mine, then the parser
situation would be alleviated, and no real threading/locks/reentracy
checking would be necessary. Buy interpreter simulated threads would
still stop all threads for blocking calls.
Dan
On 4/28/05, Jason Gade <guest at rapideuphoria.com> wrote:
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> Matt Lewis wrote:
> >
> > Jason Gade wrote:
> > >
> > > <snip much talk about threads>
> > >
> > > First let me say that I really don't think that Euphoria needs thread=
s. I don't believe
> > > that the language needs the extra complication.
> > >
> > > Any program that needs simulated threads instead of multiple processe=
s can make an
> > > event loop and set up either round-robin or timer callbacks.
> > >
> >
> > The real argument for threads, IMHO, is that the current thinking is th=
at
> > we're at a virtual dead end as far as processor performance goes, and t=
he
> > future is in multi-cored machines, which a single thread can't take
> > advantage of. It's perhaps not Euphoria's most common use, but for tho=
se
> > of us who do calculations or simulations in Euphoria, this could be rea=
lly
> > important. Multiple processes are an option, but may not be the easies=
t
> > or best way to implement a given algorithm. Not to mention the backgro=
und
> > processing that a game might be doing.
> >
> > And while processes are cheaper than threads in the Win32 realm, it's n=
ot
> > so in the *nix universe.
> >
> > Matt Lewis
> >
>
> Aren't threads lightweight processes by definition? I think that threads=
are "cheaper" than processes in any context.
>
> But I think you are right in that processes are cheaper in win32 than in =
*nix. But *nix has a longer history of multi-processing (background proces=
ses) than in threads.
>
> I think for games, the simulated approach would still probably be best. =
But I do understand that scientific simulation usually uses threads. I cer=
tainly don't know much about it, though.
>
> Are there enough people doing complex simulation in Euphoria to make it w=
orthwhile? Are there better tools than Euphoria for the job?
>
> I'm not really against it as long as it is kept simple; I just see little=
need for it by the majority of users. And as I said in another post, Euph=
oria has some things that are more important to implement or fix first.
>
> =========================
=============
> Too many freaks, not enough circuses.
>
> j.
>
>
>
>
>
17. Re: Threads [Was: Re: 64 bit euphoria]
codepilot Gmail Account wrote:
>
> Way back when I made my own eueu, it was simulating multithreading. It
> would make multiple instances of the local variables, and make the
> globals global. It would call do_instuction a few times, then
> switch_instance, and do_instruction some more. If threading was
> simulated at the interpreter level, like mine, then the parser
> situation would be alleviated, and no real threading/locks/reentracy
> checking would be necessary. Buy interpreter simulated threads would
> still stop all threads for blocking calls.
> Dan
Right, I forgot to mention. If using simulated threading the programmer must
ensure that no thread blocks or takes an excessive amount of time to run. It
basically boils down to cooperative threading.
=====================================
Too many freaks, not enough circuses.
j.
18. Re: Threads [Was: Re: 64 bit euphoria]
On 4/28/05, Jason Gade <guest at rapideuphoria.com> wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> codepilot Gmail Account wrote:
> >
> > Way back when I made my own eueu, it was simulating multithreading. It
> > would make multiple instances of the local variables, and make the
> > globals global. It would call do_instuction a few times, then
> > switch_instance, and do_instruction some more. If threading was
> > simulated at the interpreter level, like mine, then the parser
> > situation would be alleviated, and no real threading/locks/reentracy
> > checking would be necessary. Buy interpreter simulated threads would
> > still stop all threads for blocking calls.
> > Dan
>
> Right, I forgot to mention. If using simulated threading the programmer =
must ensure that no thread blocks or takes an excessive amount of time to r=
un. It basically boils down to cooperative threading.
If the interpreter has simulated threads, then threads can't take too
long(cause there each given a number of instructions), but a blocking
call will stop them all.
Dan
>
>
> =========================
=============
> Too many freaks, not enough circuses.
>
> j.
>
>
>
>
>
19. Re: Threads [Was: Re: 64 bit euphoria]
codepilot Gmail Account wrote:
>
> On 4/28/05, Jason Gade <guest at rapideuphoria.com> wrote:
> >
> >
> > posted by: Jason Gade <jaygade at yahoo.com>
> >
> > codepilot Gmail Account wrote:
> > >
> > > Way back when I made my own eueu, it was simulating multithreading. It
> > > would make multiple instances of the local variables, and make the
> > > globals global. It would call do_instuction a few times, then
> > > switch_instance, and do_instruction some more. If threading was
> > > simulated at the interpreter level, like mine, then the parser
> > > situation would be alleviated, and no real threading/locks/reentracy
> > > checking would be necessary. Buy interpreter simulated threads would
> > > still stop all threads for blocking calls.
> > > Dan
> >
> > Right, I forgot to mention. If using simulated threading the programmer =
> must ensure that no thread blocks or takes an excessive amount of time to r=
> un. It basically boils down to cooperative threading.
> If the interpreter has simulated threads, then threads can't take too
> long(cause there each given a number of instructions), but a blocking
> call will stop them all.
> Dan
Okay, I'm thinking more along the lines of a master loop that keeps a queue of
threads to run, calls each of them in turn (and each thread is specifically
written to *not* block and to only do a small piece of work before returning).
Each individual thread knows where it is in its work and whether it is finished.
Kind of like Langwar (which I haven't looked at in a long time).
=====================================
Too many freaks, not enough circuses.
j.
20. Re: Threads [Was: Re: 64 bit euphoria]
- Posted by codepilot Gmail Account <codepilot at gmail.com>
Apr 28, 2005
-
Last edited Apr 29, 2005
On 4/28/05, Jason Gade <guest at rapideuphoria.com> wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> codepilot Gmail Account wrote:
> >
> > On 4/28/05, Jason Gade <guest at rapideuphoria.com> wrote:
> > >
> > >
> > > posted by: Jason Gade <jaygade at yahoo.com>
> > >
> > > codepilot Gmail Account wrote:
> > > >
> > > > Way back when I made my own eueu, it was simulating multithreading.=
It
> > > > would make multiple instances of the local variables, and make the
> > > > globals global. It would call do_instuction a few times, then
> > > > switch_instance, and do_instruction some more. If threading was
> > > > simulated at the interpreter level, like mine, then the parser
> > > > situation would be alleviated, and no real threading/locks/reentrac=
y
> > > > checking would be necessary. Buy interpreter simulated threads woul=
d
> > > > still stop all threads for blocking calls.
> > > > Dan
> > >
> > > Right, I forgot to mention. If using simulated threading the program=
mer =
> > must ensure that no thread blocks or takes an excessive amount of time =
to r=
> > un. It basically boils down to cooperative threading.
>
> > If the interpreter has simulated threads, then threads can't take too
> > long(cause there each given a number of instructions), but a blocking
> > call will stop them all.
> > Dan
>
> Okay, I'm thinking more along the lines of a master loop that keeps a que=
ue of threads to run, calls each of them in turn (and each thread is specif=
ically written to *not* block and to only do a small piece of work before r=
eturning). Each individual thread knows where it is in its work and whethe=
r it is finished.
I've done that before, I goes pretty fast, and smooth, but I'm talking
about doing that inside the interpreter, and have multiple streams of
Intermediate Language running in the interpreter at the same time, so
your threads don't have to be cooperative.
Dan
>
> Kind of like Langwar (which I haven't looked at in a long time).
>
> =========================
=============
> Too many freaks, not enough circuses.
>
> j.
>
>
>
>
>
21. Re: Threads [Was: Re: 64 bit euphoria]
In my opinion multi thread support built in to the interpretor pointless. The
best way to perform multi threading is to use Intel's Hyper-Threading support
or the Win32 Multi threading APIs. The link below shows how to create threads
useing the Win32 API's. It is a very comprehensive reference to multi thread
techneques that can be applied on a cross platform basis. Also demonstrates
how to avoid Hyper-Technology stack conflict's and has variouse code snippets
that can be applied to Euphoria.
http://cache-www.intel.com/cd/00/00/05/15/51534_developing_multithreaded_applications.pdf
22. Re: Threads [Was: Re: 64 bit euphoria]
- Posted by Mario Steele <eumario at trilake.net>
Apr 29, 2005
-
Last edited Apr 30, 2005
Several things to note here, both on Emulated Threads, and the Hyper Threading
stuff.
First off, Emulated Threads. Yes, this is a great idea, till you run into 1
small problem. You hit a litteral brick wall, when you attempt to use C API,
that is a BLOCK call. Your whole program stops, even when running emulated
threads, and your program won't do anything, till that call is finished, and
during which time, it is very well possible, if not definate, that the entire
thread system will get knocked out of balance, and causing some fatal errors.
If you do not belive it yourself, test it with any of the BLOCKING calls of the
Winsock library, or even File I/O, let alone any C/C++ API that does not return
control to the caller, till it has finished. You will see, that this will throw
everything right out the door.
As for Hyper Threading, and Wrapping Thread ideas. Yes, this can be done. Can
it be done safely? No. Will it actually work? Most likely not. Why? Cause
Euphoria isn't designed to be Thread Safe. It isn't designed to have multiple
instances of Euphoria code, to be running con-currently. In other words people
if prodcedure a was called, it will not allow procedure b to be called, or
executed till a is finished. And therefore, that leads us back to the entire
point of Threads in Euphoria.
Rob has said this, and I'll say it again. Euphoria cannot do threads naturally,
till Threads are implemented at the Interpreter Level, and not as emulated, but
true Threads. For the simple fact, that the interpreter is only concerned for
running the current instruction, and accomplishing it, before moving on to the
next instruction. That is the entirety of needing threads in Euphoria.
*steps off the podium, and walks away*
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
23. Re: Threads [Was: Re: 64 bit euphoria]
>From: Hayden McKay <guest at RapidEuphoria.com>
>Reply-To: EUforum at topica.com
>To: EUforum at topica.com
>Subject: Re: Threads [Was: Re: 64 bit euphoria]
>Date: Thu, 28 Apr 2005 18:17:03 -0700
>
>
>posted by: Hayden McKay <hmck1 at dodo.com.au>
>
>In my opinion multi thread support built in to the interpretor pointless.
>The
>best way to perform multi threading is to use Intel's Hyper-Threading
>support
>or the Win32 Multi threading APIs. The link below shows how to create
>threads
>useing the Win32 API's. It is a very comprehensive reference to multi
>thread
>techneques that can be applied on a cross platform basis. Also demonstrates
>how to avoid Hyper-Technology stack conflict's and has variouse code
>snippets
>that can be applied to Euphoria.
>
>>http://cache-www.intel.com/cd/00/00/05/15/51534_developing_multithreaded_applications.pdf
>
I also do not find it necessary to have a multi-threading *API* in the
interpreter. However, it is necessary for there to be multi-threading
support. The Win32 Multi-threading API and Intel's Hyper-Threading (which
needs threads to do anything anyway) really don't make a difference if the
interpreter is not thread-safe. You *cannot* use them without thread-safety.
I have tried several API's; it does not work.
~[ WingZone ]~
http://wingzone.tripod.com/
24. Re: Threads [Was: Re: 64 bit euphoria]
- Posted by codepilot Gmail Account <codepilot at gmail.com>
Apr 29, 2005
-
Last edited Apr 30, 2005
On 4/29/05, Mario Steele <guest at rapideuphoria.com> wrote:
>
> posted by: Mario Steele <eumario at trilake.net>
>
> Several things to note here, both on Emulated Threads, and the Hyper Thre=
ading
> stuff.
>
> First off, Emulated Threads. Yes, this is a great idea, till you run int=
o 1
> small problem. You hit a litteral brick wall, when you attempt to use C =
API,
> that is a BLOCK call. Your whole program stops, even when running emulat=
ed
> threads, and your program won't do anything, till that call is finished, =
and
> during which time, it is very well possible, if not definate, that the en=
tire
> thread system will get knocked out of balance, and causing some fatal err=
ors.
>
> If you do not belive it yourself, test it with any of the BLOCKING calls =
of the
> Winsock library, or even File I/O, let alone any C/C++ API that does not =
return
> control to the caller, till it has finished. You will see, that this wil=
l throw
> everything right out the door.
Well mabey not, you could put emulated threads in the euphoria
interpreter, and change the c_proc/c_func code so that when its
called, it makes a new Real thread thats call the dll function
desired, while the real thread is active block the one emulated thread
that called it, allowing the other fake threads to keep running. When
the c_func is done, the Real thread dies, and the interpreter polls to
see that it died and the return value is given to the fake thread that
called it, and reactivated.
So there you have it, one main thread for the interpreter that is
split into fake threads of euphoria, and as many new real threads as
nessasary to call blocking C code. No need to majorly redesign the
interpreter, just add some support for fake threading, and change the
c_func/proc to fork.
Dan
>
> As for Hyper Threading, and Wrapping Thread ideas. Yes, this can be done=
. Can
> it be done safely? No. Will it actually work? Most likely not. Why? =
Cause
> Euphoria isn't designed to be Thread Safe. It isn't designed to have mul=
tiple
> instances of Euphoria code, to be running con-currently. In other words =
people
> if prodcedure a was called, it will not allow procedure b to be called, o=
r
> executed till a is finished. And therefore, that leads us back to the en=
tire
> point of Threads in Euphoria.
>
> Rob has said this, and I'll say it again. Euphoria cannot do threads nat=
urally,
> till Threads are implemented at the Interpreter Level, and not as emulate=
d, but
> true Threads. For the simple fact, that the interpreter is only concerne=
d for
> running the current instruction, and accomplishing it, before moving on t=
o the
> next instruction. That is the entirety of needing threads in Euphoria.
>
> *steps off the podium, and walks away*
>
> Mario Steele
> http://enchantedblade.trilake.net
> Attaining World Dominiation, one byte at a time...
>
>
>
>
>
25. Re: Threads [Was: Re: 64 bit euphoria]
On Fri, 29 Apr 2005 16:27:56 -0700, codepilot Gmail Account
<codepilot at gmail.com> wrote:
>change the c_proc/c_func code so that when its
>called, it makes a new Real thread thats call the dll function
>desired,
Wouldn't that be rather expensive?
Pete
26. Re: Threads [Was: Re: 64 bit euphoria]
codepilot Gmail Account wrote:
> Well mabey not, you could put emulated threads in the euphoria
> interpreter, and change the c_proc/c_func code so that when its
> called, it makes a new Real thread thats call the dll function
> desired, while the real thread is active block the one emulated thread
> that called it, allowing the other fake threads to keep running. When
> the c_func is done, the Real thread dies, and the interpreter polls to
> see that it died and the return value is given to the fake thread that
> called it, and reactivated.
> So there you have it, one main thread for the interpreter that is
> split into fake threads of euphoria, and as many new real threads as
> nessasary to call blocking C code. No need to majorly redesign the
> interpreter, just add some support for fake threading, and change the
> c_func/proc to fork.
> Dan
Okay, so I see, you would suggest making c_func/c_proc into threads, and
have it do it's dirty work, so that Euphoria could continue with it's own
thread..... Hmmm... very intresting idea, except for the fact, of several
things.... Memory, call_back(), and external method of calling C Routines.
Yes, you can call C routines, without needing to use c_func/c_proc. Matt
Lewis developed a library expressly for this, back when Euphoria didn't
support cdecl calling conventions.
As for call_back(), what happens if you call a blocking function, that
expressly calls a Euphoria routine to proccess information? How exactly
would you avoid the Paradox of this sistuation? Not to mention all the
chances there could be for Memory Access Violations.
Either way you look, if you want threads, you might as well go into natural
threads, not emulated threads, cause you create to many paradoxes, and end
up finding, that natural threads are actually the easiest way to go, instead
of emulated threads, and again, this strange concept, that I keep saying,
called "Re-invent the wheel."
What does Re-Invent the wheel mean? It means, You re-create a design, to
do what you want, when really, the wheel already exists. I just want to make
this clear, that I'm not against Emulated Threads, I'm not against
Sub-Proccesses, cause after all, I'm one of the people who proved you could
share memory between 2 Euphoria applications in the first place. But, the
reason I did it, was because, there was no thread support in Euphoria, or
ways to create Shared Library Modules (AKA Plugins), at the Euphoria level,
without the need to translate Euphoria into C/C++ DLL/SO's.
Elliott S. de Andrade was nice enough to port the Memory Sharing library that
me and Jason Mirwald worked on for Windows, into the Linux Realm, and I still
belive that Shared memory, and Sub-Proccesses have their place in Euphoria,
as well as Emulated Threads. However, just because we have the ability to
do these two things, doesn't mean that they are full replacements for
Full Thread Support.
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
27. Re: Threads [Was: Re: 64 bit euphoria]
Well, emulated threads (at the interpreter level) are good enough for Ruby
http://www.rubycentral.com/book/tut_threads.html and mixed threads are good
enough for Python http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf
Gnu pth also uses emulated threads for the C language
http://heather.cs.ucdavis.edu/~matloff/pth.html
Of course all of these require interpreter support, as opposed to the library
method that I am advocating.
I did a little Google research and found that OS threads and so-called
"emulated" threads have their advantages and disadvantages.
Would it be less work to support threads in the language by emulation or would
it be easier to make the language support OS-level threads using OS libraries?
(pthreads for *nix and whatever Windows uses for itself?)
I still think that it is a solution in search of a problem, though. Anything
requiring the difficulty of writing a threaded application may as well be written
in another language.
=====================================
Too many freaks, not enough circuses.
j.
28. Re: Threads [Was: Re: 64 bit euphoria]
On 4/29/05, Mario Steele <guest at rapideuphoria.com> wrote:
>
>
> posted by: Mario Steele <eumario at trilake.net>
>
> codepilot Gmail Account wrote:
> > Well mabey not, you could put emulated threads in the euphoria
> > interpreter, and change the c_proc/c_func code so that when its
> > called, it makes a new Real thread thats call the dll function
> > desired, while the real thread is active block the one emulated thread
> > that called it, allowing the other fake threads to keep running. When
> > the c_func is done, the Real thread dies, and the interpreter polls to
> > see that it died and the return value is given to the fake thread that
> > called it, and reactivated.
> > So there you have it, one main thread for the interpreter that is
> > split into fake threads of euphoria, and as many new real threads as
> > nessasary to call blocking C code. No need to majorly redesign the
> > interpreter, just add some support for fake threading, and change the
> > c_func/proc to fork.
> > Dan
>
> Okay, so I see, you would suggest making c_func/c_proc into threads, and
> have it do it's dirty work, so that Euphoria could continue with it's own
> thread..... Hmmm... very intresting idea, except for the fact, of several
> things.... Memory, call_back(), and external method of calling C Routine=
s.
>
> Yes, you can call C routines, without needing to use c_func/c_proc. Matt
> Lewis developed a library expressly for this, back when Euphoria didn't
> support cdecl calling conventions.
>
> As for call_back(), what happens if you call a blocking function, that
> expressly calls a Euphoria routine to proccess information? How exactly
> would you avoid the Paradox of this sistuation? Not to mention all the
> chances there could be for Memory Access Violations.
>
With the emulated threads at interpreter level, one dirty work real
thread for each fake thread could have all the callbacks in it that
just set a semiphore that reactivates the fake thread and waits for a
return, then runs again.
And what do you mean by a Memory Access Violation? How is one possible
when the fake thread is locked until the worker thread is done?
Dan
> Either way you look, if you want threads, you might as well go into natur=
al
> threads, not emulated threads, cause you create to many paradoxes, and en=
d
> up finding, that natural threads are actually the easiest way to go, inst=
ead
> of emulated threads, and again, this strange concept, that I keep saying,
> called "Re-invent the wheel."
>
> What does Re-Invent the wheel mean? It means, You re-create a design, to
> do what you want, when really, the wheel already exists. I just want to =
make
> this clear, that I'm not against Emulated Threads, I'm not against
> Sub-Proccesses, cause after all, I'm one of the people who proved you cou=
ld
> share memory between 2 Euphoria applications in the first place. But, th=
e
> reason I did it, was because, there was no thread support in Euphoria, or
> ways to create Shared Library Modules (AKA Plugins), at the Euphoria leve=
l,
> without the need to translate Euphoria into C/C++ DLL/SO's.
>
> Elliott S. de Andrade was nice enough to port the Memory Sharing library =
that
> me and Jason Mirwald worked on for Windows, into the Linux Realm, and I s=
till
> belive that Shared memory, and Sub-Proccesses have their place in Euphori=
a,
> as well as Emulated Threads. However, just because we have the ability t=
o
> do these two things, doesn't mean that they are full replacements for
> Full Thread Support.
>
> Mario Steele
> http://enchantedblade.trilake.net
> Attaining World Dominiation, one byte at a time...
>
>
>
>
>
29. Re: Threads [Was: Re: 64 bit euphoria]
On 4/29/05, Jason Gade <guest at rapideuphoria.com> wrote:
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> Well, emulated threads (at the interpreter level) are good enough for Rub=
y http://www.rubycentral.com/book/tut_threads.html and mixed threads are go=
od enough for Python http://heather.cs.ucdavis.edu/~matloff/Python/PyThread=
s.pdf
>
> Gnu pth also uses emulated threads for the C language http://heather.cs.u=
cdavis.edu/~matloff/pth.html
>
> Of course all of these require interpreter support, as opposed to the lib=
rary method that I am advocating.
>
> I did a little Google research and found that OS threads and so-called "e=
mulated" threads have their advantages and disadvantages.
>
> Would it be less work to support threads in the language by emulation or =
would it be easier to make the language support OS-level threads using OS l=
ibraries? (pthreads for *nix and whatever Windows uses for itself?)
>
> I still think that it is a solution in search of a problem, though. Anyt=
hing requiring the difficulty of writing a threaded application may as well=
be written in another language.
>
Every time someone says "may as well be written in another language."
someone does, and that's where all our new users keep disappearing off
too.
Dan
> =========================
=============
> Too many freaks, not enough circuses.
>
> j.
>
>
>
>
>
30. Re: Threads [Was: Re: 64 bit euphoria]
On 4/29/05, codepilot Gmail Account <codepilot at gmail.com> wrote:
>
> On 4/29/05, Mario Steele <guest at rapideuphoria.com> wrote:
> >
> >
> > posted by: Mario Steele <eumario at trilake.net>
> >
> > codepilot Gmail Account wrote:
> > > Well mabey not, you could put emulated threads in the euphoria
> > > interpreter, and change the c_proc/c_func code so that when its
> > > called, it makes a new Real thread thats call the dll function
> > > desired, while the real thread is active block the one emulated threa=
d
> > > that called it, allowing the other fake threads to keep running. When
> > > the c_func is done, the Real thread dies, and the interpreter polls t=
o
> > > see that it died and the return value is given to the fake thread tha=
t
> > > called it, and reactivated.
> > > So there you have it, one main thread for the interpreter that is
> > > split into fake threads of euphoria, and as many new real threads as
> > > nessasary to call blocking C code. No need to majorly redesign the
> > > interpreter, just add some support for fake threading, and change the
> > > c_func/proc to fork.
> > > Dan
> >
> > Okay, so I see, you would suggest making c_func/c_proc into threads, an=
d
> > have it do it's dirty work, so that Euphoria could continue with it's o=
wn
> > thread..... Hmmm... very intresting idea, except for the fact, of sever=
al
> > things.... Memory, call_back(), and external method of calling C Routi=
nes.
> >
> > Yes, you can call C routines, without needing to use c_func/c_proc. Ma=
tt
> > Lewis developed a library expressly for this, back when Euphoria didn't
> > support cdecl calling conventions.
> >
> > As for call_back(), what happens if you call a blocking function, that
> > expressly calls a Euphoria routine to proccess information? How exactl=
y
> > would you avoid the Paradox of this sistuation? Not to mention all the
> > chances there could be for Memory Access Violations.
> >
> With the emulated threads at interpreter level, one dirty work real
> thread for each fake thread could have all the callbacks in it that
> just set a semiphore that reactivates the fake thread and waits for a
> return, then runs again.
> And what do you mean by a Memory Access Violation? How is one possible
> when the fake thread is locked until the worker thread is done?
> Dan
I was just thinking, and I think its possible to make a library in
euphoria and asm that forks for c_func/procs and does something else
while the call is going on and returns to the same spot when the call
is done. But this wouldn't solve the one euphoria part taking forever
and slowing down things, but it could get rid of the blocking problem.
Dan
> > Either way you look, if you want threads, you might as well go into nat=
ural
> > threads, not emulated threads, cause you create to many paradoxes, and =
end
> > up finding, that natural threads are actually the easiest way to go, in=
stead
> > of emulated threads, and again, this strange concept, that I keep sayin=
g,
> > called "Re-invent the wheel."
> >
> > What does Re-Invent the wheel mean? It means, You re-create a design, =
to
> > do what you want, when really, the wheel already exists. I just want t=
o make
> > this clear, that I'm not against Emulated Threads, I'm not against
> > Sub-Proccesses, cause after all, I'm one of the people who proved you c=
ould
> > share memory between 2 Euphoria applications in the first place. But, =
the
> > reason I did it, was because, there was no thread support in Euphoria, =
or
> > ways to create Shared Library Modules (AKA Plugins), at the Euphoria le=
vel,
> > without the need to translate Euphoria into C/C++ DLL/SO's.
> >
> > Elliott S. de Andrade was nice enough to port the Memory Sharing librar=
y that
> > me and Jason Mirwald worked on for Windows, into the Linux Realm, and I=
still
> > belive that Shared memory, and Sub-Proccesses have their place in Eupho=
ria,
> > as well as Emulated Threads. However, just because we have the ability=
to
> > do these two things, doesn't mean that they are full replacements for
> > Full Thread Support.
> >
> > Mario Steele
> > http://enchantedblade.trilake.net
> > Attaining World Dominiation, one byte at a time...
> >
> >
>
>
31. Re: Threads [Was: Re: 64 bit euphoria]
codepilot Gmail Account wrote:
>
> On 4/29/05, codepilot Gmail Account <codepilot at gmail.com> wrote:
> >
> > On 4/29/05, Mario Steele <guest at rapideuphoria.com> wrote:
> > >
> > >
> > > posted by: Mario Steele <eumario at trilake.net>
> > >
> > > codepilot Gmail Account wrote:
> > > > Well mabey not, you could put emulated threads in the euphoria
> > > > interpreter, and change the c_proc/c_func code so that when its
> > > > called, it makes a new Real thread thats call the dll function
> > > > desired, while the real thread is active block the one emulated threa=
> d
> > > > that called it, allowing the other fake threads to keep running. When
> > > > the c_func is done, the Real thread dies, and the interpreter polls t=
> o
> > > > see that it died and the return value is given to the fake thread tha=
> t
> > > > called it, and reactivated.
> > > > So there you have it, one main thread for the interpreter that is
> > > > split into fake threads of euphoria, and as many new real threads as
> > > > nessasary to call blocking C code. No need to majorly redesign the
> > > > interpreter, just add some support for fake threading, and change the
> > > > c_func/proc to fork.
> > > > Dan
> > >
> > > Okay, so I see, you would suggest making c_func/c_proc into threads, an=
> d
> > > have it do it's dirty work, so that Euphoria could continue with it's o=
> wn
> > > thread..... Hmmm... very intresting idea, except for the fact, of sever=
> al
> > > things.... Memory, call_back(), and external method of calling C Routi=
> nes.
> > >
> > > Yes, you can call C routines, without needing to use c_func/c_proc. Ma=
> tt
> > > Lewis developed a library expressly for this, back when Euphoria didn't
> > > support cdecl calling conventions.
> > >
> > > As for call_back(), what happens if you call a blocking function, that
> > > expressly calls a Euphoria routine to proccess information? How exactl=
> y
> > > would you avoid the Paradox of this sistuation? Not to mention all the
> > > chances there could be for Memory Access Violations.
> > >
> > With the emulated threads at interpreter level, one dirty work real
> > thread for each fake thread could have all the callbacks in it that
> > just set a semiphore that reactivates the fake thread and waits for a
> > return, then runs again.
> > And what do you mean by a Memory Access Violation? How is one possible
> > when the fake thread is locked until the worker thread is done?
> > Dan
> I was just thinking, and I think its possible to make a library in
> euphoria and asm that forks for c_func/procs and does something else
> while the call is going on and returns to the same spot when the call
> is done. But this wouldn't solve the one euphoria part taking forever
> and slowing down things, but it could get rid of the blocking problem.
> Dan
>
> > > Either way you look, if you want threads, you might as well go into nat=
> ural
> > > threads, not emulated threads, cause you create to many paradoxes, and =
> end
> > > up finding, that natural threads are actually the easiest way to go, in=
> stead
> > > of emulated threads, and again, this strange concept, that I keep sayin=
> g,
> > > called "Re-invent the wheel."
> > >
> > > What does Re-Invent the wheel mean? It means, You re-create a design, =
> to
> > > do what you want, when really, the wheel already exists. I just want t=
> o make
> > > this clear, that I'm not against Emulated Threads, I'm not against
> > > Sub-Proccesses, cause after all, I'm one of the people who proved you c=
> ould
> > > share memory between 2 Euphoria applications in the first place. But, =
> the
> > > reason I did it, was because, there was no thread support in Euphoria, =
> or
> > > ways to create Shared Library Modules (AKA Plugins), at the Euphoria le=
> vel,
> > > without the need to translate Euphoria into C/C++ DLL/SO's.
> > >
> > > Elliott S. de Andrade was nice enough to port the Memory Sharing librar=
> y that
> > > me and Jason Mirwald worked on for Windows, into the Linux Realm, and I=
> still
> > > belive that Shared memory, and Sub-Proccesses have their place in Eupho=
> ria,
> > > as well as Emulated Threads. However, just because we have the ability=
> to
> > > do these two things, doesn't mean that they are full replacements for
> > > Full Thread Support.
> > >
> > > Mario Steele
> > > <a
> > > href="http://enchantedblade.trilake.net">http://enchantedblade.trilake.net</a>
> > > Attaining World Dominiation, one byte at a time...
> > >
> > >
What Rob should do, is overhaul Euphoria at the interpreter level to use
C code that is thread safe, then add support for multiple call stacks,
data structs, etc.. (to allow thread safety).
Rob then can make an "external" thread library (eg: threads.e), that
offers all the basic thread functionability; like routines/variables
for creating, destroying, starting, sleeping, yielding, state testing, priority
execution, execution timing, so on. This idea can relate to
Java, in that it has a few basic threading class libraries part of
the J2SE/JRE framework.
Regards,
Vincent
--
Without walls and fences, there is no need for Windows and Gates.
32. Re: Threads [Was: Re: 64 bit euphoria]
Vincent wrote:
> What Rob should do, is overhaul Euphoria at the interpreter level to use
> C code that is thread safe, then add support for multiple call stacks,
> data structs, etc.. (to allow thread safety).
>
> Rob then can make an "external" thread library (eg: threads.e), that
> offers all the basic thread functionability; like routines/variables
> for creating, destroying, starting, sleeping, yielding, state testing,
> priority execution,
> execution timing, so on. This idea can relate to
> Java, in that it has a few basic threading class libraries part of
> the J2SE/JRE framework.
>
>
> Regards,
> Vincent
If this is so easy why not buy the source code and
show Rob how to do it !
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
33. Re: Threads [Was: Re: 64 bit euphoria]
On 4/30/05, Bernie Ryan <guest at rapideuphoria.com> wrote:
>
> posted by: Bernie Ryan <xotron at bluefrog.com>
>
> Vincent wrote:
> > What Rob should do, is overhaul Euphoria at the interpreter level to us=
e
> > C code that is thread safe, then add support for multiple call stacks,
> > data structs, etc.. (to allow thread safety).
> >
> > Rob then can make an "external" thread library (eg: threads.e), that
> > offers all the basic thread functionability; like routines/variables
> > for creating, destroying, starting, sleeping, yielding, state testing, =
priority execution,
> > execution timing, so on. This idea can relate to
> > Java, in that it has a few basic threading class libraries part of
> > the J2SE/JRE framework.
> >
> >
> > Regards,
> > Vincent
>
> If this is so easy why not buy the source code and
> show Rob how to do it !
>
If he shows Rob how, and is responsable for a new feature, then he
deserves some of the money from the new people that buy because of it.
And thats why its Rob's job, not Vincent's or mine or anyone elses.
Dan
> Bernie
>
> My files in archive:
> w32engin.ew mixedlib.e eu_engin.e win32eru.ew
>
> Can be downloaded here:
> http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx==
on&gen=on&keywords=bernie+ryan
>
>
>
>
>
34. Re: Threads [Was: Re: 64 bit euphoria]
On 28 Apr 2005, at 12:04, Jason Gade wrote:
>
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> codepilot Gmail Account wrote:
> >
> > Way back when I made my own eueu, it was simulating multithreading. It
> > would make multiple instances of the local variables, and make the
> > globals global. It would call do_instuction a few times, then
> > switch_instance, and do_instruction some more. If threading was
> > simulated at the interpreter level, like mine, then the parser
> > situation would be alleviated, and no real threading/locks/reentracy
> > checking would be necessary. Buy interpreter simulated threads would
> > still stop all threads for blocking calls.
> > Dan
>
> Right, I forgot to mention. If using simulated threading the programmer must
> ensure that no thread blocks or takes an excessive amount of time to run. It
> basically boils down to cooperative threading.
Which is windose 3.11, and why i was rather excited to see the "windows
server" in the archives. It's basically win3.11 in Eu, on top of whatever OS
you use now.
Kat
