Re: Someone changed my Thread Manager writeup?
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 10, 2005
- 553 views
Al Getz wrote: > When i posted my Thread Manager this morning the writeup i sent with > it was this: > > Dont let the small file size fool you...this 1200 byte Thread Manager takes > care of background processing allowing your app to function normally even > during long operations like file saves. Start 1 or 1000 threads while the > user can still click buttons and move the window around, all while the > Marquee control shows there are still pending operations to be completed. > > > When i see it posted, the writeup got changed to this: > > A simple technique for simulating multiple threads for his WinClass > library, though it could likely be used with any GUI library. It > allows your app to function normally even during long operations > like file saves. Run numerous background threads while the user can > still click buttons and move the window around. His demo has a Marquee > control that shows there are still pending operations to be completed. > Note: there is no scheduling mechanism. Just the call stack. > Real O/S threads are not used. > > > How did this get changed and who did it and why? Anything that is submitted to User Contributions is subject to editing. Many descriptions have some editing, in the interest of fixing spelling, grammar, removing excessive "hype" etc. as well as making it clearer to people what the program really does. In your case I felt that a lot of people would be misled by your "Thread Manager" description into thinking that you had implemented a general form of threads in Euphoria, something that people have asked for, and that I am currently working on, though I won't use O/S threads, but rather "cooperative multitasking" with multiple subroutine call stacks. Here is your *entire* "Thread Manager 01"...
atom Thread sequence Ts global procedure ResetThreads() --This is mainly used to reset Thread count to zero. --Normally this wont be needed. Thread=0 Ts={} end procedure ResetThreads() global function GetCurrentThread() return Thread end function global procedure ContinueThread(atom TimeSlice) Ts[Thread]=time()+TimeSlice end procedure global function CheckThread() if time()>Ts[Thread] then return 1 else return 0 end if end function global procedure StartThread(atom TimeSlice) Ts=append(Ts,time()+TimeSlice) Thread=length(Ts) end procedure global procedure EndThread() Ts=Ts[1..length(Ts)-1] Thread=length(Ts) end procedure
I think what you've done would be useful for certain applications. There's nothing wrong with it, as far as it goes, and I'm glad to have it in User Contributions. But to call it a "Thread Manager" (I left your title as is) and then talk about creating thousands of threads etc. without explaining better what it really is would confuse many people. In a previous message you wrote: > If there's any difference between this and a 'real' thread i'd like > to see it, at least from a software point of view :) Your "thread manager" - does not support O/S (pre-emptive) threads in any way Many people assume that if something is called a "thread" it uses pre-emptive O/S threads. - does not have a separate call stack for each "thread". That seems to be the bottom line for any form of threading or tasking that you'll find discusssed on the Web - has no scheduler. i.e. no way of specifying the timing of when a "thread" should run (other than the user clicking something), and no way of setting priorities - transfers control from one "thread" to another via call/return so a thread can only get control after a return from all the other stacked calls to other "threads", including possible calls to itself. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com