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