Re: Someone changed my Thread Manager writeup?
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'?
Rob:
QUOTE
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.
END QUOTE
I think i see what you mean, but for lack of a better description
i called it 'threads', not to deceive people (who would eventually
figure out it's not 'true' threads) but to lead them to look at
alternate ways of handling multitasking and long operations without
jamming up the gui. If you tell some people looking for what they
think threads are that it's not really threads, they might think
it's not useful for an application that can very well work as well
as with 'true' threads...they'll overlook it.
You note yourself that there are lots of 'types' of threads, and that since
there are operations pending while other operations are taking place
there is a default task scheduler, even though it lacks some 'true'
thread behaviour. The next thread that comes up takes control and
doesnt have to wait for pending threads to complete. It's thus
a "last-in-first-complete" task scheduler.
BTW, what would you call it (single word or two?) if not 'threads'?
Since it acts something like threads act (software control) i dont
see anything wrong with calling it threads, although i do see a
better explanation would be good as you provided.
Note also that if you tell some people:
Note: there is no scheduling mechanism.
Just the call stack.
Real O/S threads are not used.
This is certainly not real threads!
Watch out, this isnt real threads!
Real threads arent used.
Threads that appear real arent!
Threads that appear in mirror arent as big as they look!
They might get the idea that it isnt useful with software the way
'True' threads are :)
Im not asking you to change the writeup however, because i agree there
should be more of an explanation as you noted :)
I guess i could add a scheduling mechanism if that would make more
people happy :) That way they will get almost the same operation only
with a bigger file length :)
Ok, so then they would have a choice...but notice i didnt name the file:
"ThreadManager.ew"
but rather:
"TheadManager01.ew"
to make room for "ThreadManager02.ew", "ThreadManager03.ew", etc.
People would then have the choice between using this type of
'threading' or an actual thread scheduler.
I was tempted to call this technique "Messaging Threads" but that
sounds so dumb :) (because 'threads' are basically created via Windows
messages).
Kat:
I really think you should try a few applications using this kind of
technique before you pass judgement. I've used it at least three times
already and to the gui it looks almost like threading because several
operations can be initiated and the gui isnt frozen while the operations
(such as multiple file saves) take place. It appears that the application
is always active and is performing several operations at the same time.
Anyone:
Anyone have a better name for this kind of thread-like behaviour?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
|
Not Categorized, Please Help
|
|
