OpenEuphoria

Re: Someone changed my Thread Manager writeup?

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Aug 10, 2005
• 540 views

Al Getz wrote:
> 
> Hello again and thanks for the idea/replies,
> 
> 
> Jonas:
> There's no reason why you cant end a 'thread' early, by calling EndThread().
> Just cant call EndThread() twice for the SAME thread.
> 
> Matt:
> QUOTE
>   Not that it isn't useful, but it's not really threads at all, since threads
>   would imply some sort of scheduling mechanism, as noted by Rob.
> END QUOTE
> There actually is a schedualing mechanism: "last-in-first-complete".
> Yes, it's not *really* threads, but since this technique acts so much
> like threads (from the standpoint of everything but hardware) i opted
> to call it threads...not to mislead people but to get them to look at
> alternate techniques that provide thread-like behaviour.  Note that
> there are various 'types' of threads...which one is the 'true' threading?
> Yet they are all called 'threads'.  Note also to the end user of the
> program they wont know the difference, if there ends up really being
> any anyway :)
> The only real difference is that the user must break up their long
> operation into chunks, performing a check between chunks, but this isnt hard
> to do.
> BTW, what single word name would you use to describe these pseudo 'threads'?

'call-stack'

OK, there is a 'scheduling mechanism' in the sense that you check timing,
but you're relying on the OS to do what you're talking about when you
yield to the gui, and check the event loop.  A thread implies some sort
of parallel execution.  You don't have that at all.  What you're doing
is taking a break to allow the OS to do a call_back to your event loop.
Don't get me wrong, this is incredibly useful, and every so often this
question appears on the list.  Every GUI lib has a way to deal with this.

I think the generally accepted meaning of thread comes back to either 
pre-emptive or cooperative multitasking.  You actually do neither.  It's
just a call stack.  You start in your event loop.  Eventually some process
happens.  It takes longer than is acceptable, so you yield to the GUI.
There are some events queued up, and one at a time, they are handled.  Some
of these events may even take a while, and you may yield to the GUI yet
again, and so forth.  Eventually, your handlers finish and you work your
way back up the call stack.  I may as well call a program that calls several
routines from each other 'threaded'.  Your definition of threading has no
meaning.

Matt Lewis