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...
>
>
>
>
>
|
Not Categorized, Please Help
|
|
