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

new topic     » goto parent     » topic index » view thread      » older message » newer message

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...

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu