Re: Threads [Was: Re: 64 bit euphoria]
- Posted by Jason Gade <jaygade at yahoo.com> Apr 28, 2005
- 509 views
<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.