OpenEuphoria

Re: Someone changed my Thread Manager writeup?

• Posted by Robert Craig <rds at RapidEuphoria.com> Aug 10, 2005
• 555 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