Re: Threads [Was: Re: 64 bit euphoria]
- Posted by Mario Steele <eumario at trilake.net> Apr 30, 2005
- 502 views
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...