Re: Someone changed my Thread Manager writeup?
Matt Lewis wrote:
> '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
>
Matt,
It does in fact use preemptive multitasking, although it's limited to
a newly started thread. Once the time slice of the current thread
is up, a new thread can start, and since this is based on elapsed
time it's basically a (limited) time sharing preemptive multitasking
type mechanism -- still very similar to threading.
To the end user, it doesnt always matter if the task order is
1 partA, 2 partA, 1 partB, 2 partB,
or
1 partA, 2 partA, 2 partB, 1 partB
as long as all the tasks get completed eventually, and of course
what most people want is mainly to prevent gui hangups.
True, this may not be desirable in all situations, but in many
it does work almost the same as 'real' threading. Since it's
that close, i call it 'threading'. Perhaps since it's not
parallel (as you mentioned) i should call it 'pseudo threading'.
At least this would convey there is 'thread like' operation
although it's not true threading.
You see, it acts so close to a thread that calling it anything else
would make it sound like it doesnt act like a thread and that too
would be misleading.
Ok, let's see...
If i call it "CallStack Manager"
no one is going to know what the heck it does :)
especially when they might be looking for a threading mechanism.
So you see the dilemma...
If it sounds better, i'll call it 'Thread Manager' but in the
(next) writeup i'll mention that it manages 'pseudo' threads...
that is, simulated threads.
"Your definition of threading has no meaning."
Well, if it has no meaning then what are we talking about?
The meaning comes from looking at the gui from the standpoint of
the user...the way the program ends up working looks wayyyy too much
like threading...hence the name. More than one operation appears to
be occuring at the same time and the gui isnt hung.
BTW a pure call stack doesnt depend on a time slice either, the
way this thread managing technique does. A call stack simply
holds a list that get executed one after the other.
Note that with this pseudo threading a new thread can break in
and take over any time (after the current time slice is up).
That's multitasking, even though it's not in the order you might
normally expect it to happen in.
Perhaps a better name would be Multitasking Manager? :)
But then that sounds like it manages more than one process.
See, another dilemma :)
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
|
Not Categorized, Please Help
|
|
