1. Someone changed my Thread Manager writeup?
Hello,
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?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
2. Re: Someone changed my Thread Manager writeup?
Al Getz wrote:
>
> Hello,
>
>
> 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?
Obviously, Rob did it. He often edits the descriptions. His description
is a bit less misleading, IMHO. The lib doesn't really do much. It's just
a way to see how long things have been going on since the last time you
checked. If it's been long enough, the user makes a call to the GUI lib
to check for any events that have been queued up. I might have summarized
it like this:
"A library to help keep track of how long a task has been working, so that
you can check for user events to avoid blocking the GUI."
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.
Matt Lewis
3. Re: Someone changed my Thread Manager writeup?
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
4. Re: Someone changed my Thread Manager writeup?
On 10 Aug 2005, at 7:10, Matt Lewis wrote:
>
>
> posted by: Matt Lewis <matthewwalkerlewis at gmail.com>
>
> Al Getz wrote:
> >
> > Hello,
> >
> >
> > 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?
>
> Obviously, Rob did it. He often edits the descriptions. His description
> is a bit less misleading, IMHO. The lib doesn't really do much. It's just a
> way to see how long things have been going on since the last time you checked.
>
> If it's been long enough, the user makes a call to the GUI lib to check for
> any
> events that have been queued up. I might have summarized it like this:
>
> "A library to help keep track of how long a task has been working, so that you
> can check for user events to avoid blocking the GUI."
>
> 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.
Al, i thought you were far more on the right track with your "window server". I
was serious, not making fun, when i said you'd reinvented windows 3.1. In
essence, you had done everyone using a threads a favor when you got the
premptive taskmanager (Eu thread controller) for the desktop (the Eu gui),
and could spawn as many "run ex*.exe 'filename.ew'" as needed. I'd have
stayed with that thread of development.
Kat
5. 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"
6. Re: Someone changed my Thread Manager writeup?
Hello again,
I didnt get to finish replying to Rob's post...
Rob:
QUOTE
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.
END QUOTE
It does in fact use:
"Preemptive Multitasking"
ie uses some criteria to decide how long any one task should run before
giving another task a turn to use the operating system.
Although it's not *ALL* built into the "ThreadManager" the recommended
structure for using this technique makes it preemptive.
Note the time() calls in the ThreadManager.
Again, although the ThreadManager itself doesnt contain a separate call
stack, the 'call stack' comes from the way the structure of the
way the Thread Manager is used (noted in the docs). Each entry into the
long operation function creates another pseudo 'stack'. Each thread
thus has it's own 'stack'. Other perhaps required variables may be
allocated if they are done private to the function call or using allocated
memory.
It does in fact have a scheduler...as noted before...it's just not
your 'usual' time slice mechanism. It's a last-in-first-complete schedual.
A new thread may start at any time once the time slice for the current
thread is complete...even though the entire operation of the thread isnt
yet done. Although this isnt your usual 'poll each thread' type
mechanism, to the user it looks almost the same.
Transfer of control from one 'thread' to another takes place when the
next operation is initiated. The new thread takes over and when it's
complete operation continues with the previously invoked thread.
When that thread is complete the thread before that then takes control.
Thus, if threads are initiated in this order:
1-2-3
they complete in this order:
3-2-1
Note that if thread 2 is almost done when thread 3 is initiated,
after thread 3 is complete thread 2 completes rather quickly
because it's almost done.
Note also that the demo allows multiple calls to the same 'thread' that
initiates a new thread, but in practice this might actually be blocked
by maintaining a variable to allow or prevent re-entry. For the
demo i thought it would be easier for the user to see more threads
being initiated by simply clicking the same button over and over.
I still agree however that more of an explanation would have been
better, but would like to see other users try this method before
thinking that it's not very good.
As i mentioned in a earlier post, i've used a similar technique
in a calculator program and geeze, it's like having 20 calculators
working at the same time even though there's only one gui :)
I've also used a similar technique in a C based chess program,
where some operations have to complete before the user can exit
and the gui has to be active at all times (to allow takeback while
the computer is thinking, etc.) and it looks like it's multi threaded.
Now maybe this helps explain why i said in my initial writeup:
"Dont let this small 1200 byte ThreadManager fool you" :)
Ok, so part of the 'trick' is in the structure and use of
the ThreadManager, but it's not hard to use.
I think it actually does quite a bit, and it's small, which makes
it look like it doesnt do much.
Take care,
Al
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
7. Re: Someone changed my Thread Manager writeup?
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
8. Re: Someone changed my Thread Manager writeup?
On 10 Aug 2005, at 8:48, Al Getz wrote:
>
>
> posted by: Al Getz <Xaxo at aol.com>
>
<snip>
> 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.
I thought your windows server did the same.
Kat
9. Re: Someone changed my Thread Manager writeup?
Al Getz wrote:
>
> Anyone:
> Anyone have a better name for this kind of thread-like behaviour?
>
Al,
Although I have not looked at your program, from what I am reading in these
threads (no pun intended) on your program it sounds to me like you are simulating
running simulteanous events.
Therefore, would it not be called something like Simulteanous Events Manager?
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses
Now contains an Introduction To Euphoria Programming Course At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
My Free Games Page
http://freewebtown.com/ferlin
10. Re: Someone changed my Thread Manager writeup?
Ferlin Scarborough wrote:
>
> Therefore, would it not be called something like Simulteanous Events Manager?
>
Sorry about that it should be Simultaneous Events Manager.
Later.
Ferlin Scarborough
Learn To Program Games in Free Courses
Now contains an Introduction To Euphoria Programming Course At
http://www.gameuniv.net
My Euphoria Home Page
http://mywebpage.netscape.com/shadetreesoft
My Free Games Page
http://freewebtown.com/ferlin
11. 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"
12. Re: Someone changed my Thread Manager writeup?
Hi Kat,
Well, the Display Server is more or less just another process,
and although that does mean it's another thread it's not really
set up to handle multiple threads unless you start more than
one server, but then it actually only prints and displays stuff
so i think this is a little different? My scientific function
calculator (in the archives) works in it's own process too, and
stores data and does calculations, so i guess that's closer to
a true secondary thread?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
13. Re: Someone changed my Thread Manager writeup?
Ferlin Scarborough wrote:
>
> Ferlin Scarborough wrote:
> >
> > Therefore, would it not be called something like Simulteanous Events
> > Manager?
> >
>
> Sorry about that it should be Simultaneous Events Manager.
>
> Later.
>
> Ferlin Scarborough
>
Hi Ferlin,
Well, i wanted to call it something that was already familiar to
users and not make them wonder what the heck it was :)
Right now im thinking about "Thread Manager for Pseudo Threads",
because it is in fact a threading manager, but the threads arent
'true' threads the way i think most people would expect (at least
not yet). Funny thing is, in thinking about a second version
(that allows true time slicing with the usual thread polling)
im comming up with a more complicated model that, to the end user,
will appear exactly the same for many gui applications!
Yes, it will be closer to 'true' threading, but the only one
who will know the difference will be the person that programs
the app! That's another reason why i have to call it some sort of
threading or another, even before version #2.
At least it performs a function that is useful to applications
even the way it is now, so what the heck :)
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
14. Re: Someone changed my Thread Manager writeup?
Hi Al
I think your "Thread Manager" fills an important need and would like
to thank you for developing it and then making it available to
everyone.
There are times when "simplicity" of algorithm provides speed which
enables it to match (or even out perform) more complicated predictive
algorithms in certain tasks (not necessarily all tasks). As far as
the end user is concerned, it "looks" and "performs" like its more
complicated "relative". In some cases it may even seem to the end
user to be "better".
In other words, it's about results from the end user (user of the
created software) perspective rather than method.
I find Euphoria itself to have this "quality" - an elegant
simplicity.
I would ask you not to increase the library's complication in order
to perform tasks more like a "real" thread if there is no obvious
benefit to the end user for those certain tasks it is good at.
Naturally no one tool is right for all purposes. But we now have a
tool we did not have before. Thanks.
You asked about a new name for the library. Perhaps "Software Pseudo
Threads" ?
--
David
On 10 Aug 2005 at 11:30, Al Getz wrote:
>
>
> posted by: Al Getz <Xaxo at aol.com>
>
> Ferlin Scarborough wrote:
> >
> > Ferlin Scarborough wrote:
> > >
> > > Therefore, would it not be called something like Simulteanous
> > > Events Manager?
> > >
> >
> > Sorry about that it should be Simultaneous Events Manager.
> >
> > Later.
> >
> > Ferlin Scarborough
> >
>
> Hi Ferlin,
>
>
> Well, i wanted to call it something that was already familiar to
> users and not make them wonder what the heck it was :)
>
> Right now im thinking about "Thread Manager for Pseudo Threads",
> because it is in fact a threading manager, but the threads arent
> 'true' threads the way i think most people would expect (at least
not
> yet). Funny thing is, in thinking about a second version (that
allows
> true time slicing with the usual thread polling) im comming up with
a
> more complicated model that, to the end user, will appear exactly
the
> same for many gui applications! Yes, it will be closer to 'true'
> threading, but the only one who will know the difference will be
the
> person that programs the app! That's another reason why i have to
> call it some sort of threading or another, even before version #2.
>
> At least it performs a function that is useful to applications
> even the way it is now, so what the heck :)
>
>
> Take care,
> Al
>
> And, good luck with your Euphoria programming!
>
> My bumper sticker: "I brake for LED's"
>
>
>
>
15. Re: Someone changed my Thread Manager writeup?
On 11 Aug 2005, at 10:58, David Jarvis wrote:
> You asked about a new name for the library. Perhaps "Software Pseudo
> Threads" ?
> >
> > > Ferlin Scarborough wrote:
> > > >
> > > Sorry about that it should be Simultaneous Events Manager.
> > Right now im thinking about "Thread Manager for Pseudo Threads",
How about "Kinda Almost Threads" ?
Kat
16. Re: Someone changed my Thread Manager writeup?
Hi again,
Mike:
That's an interesting idea. "Strands" sounds somewhat descriptive,
but it doesnt show the relationship to 'Threads' without further
education on the part of the user, so maybe "Thread Strands" :) ?
I'd just have to find a way to convey the meaning of what a "Strand"
is/does without using too many words...i dont want to have to write
a book to get users to understand what this does when they read
the description.
David Jarvis:
QUOTE
There are times when "simplicity" of algorithm provides speed which
enables it to match (or even out perform) more complicated predictive
algorithms in certain tasks (not necessarily all tasks). As far as
the end user is concerned, it "looks" and "performs" like its more
complicated "relative". In some cases it may even seem to the end
user to be "better".
END QUOTE
Yes, i was trying to get that message across. It's not necessarily for all
tasks, but when it is useable it's quite simple and pretty fast too.
In a true 'parallel' thread setup the order of thread processing might go:
1-2-3-1-2-3-1-2-3 (three threads that each take three time slices)
to get all three tasks done, while with this technique the processing would
go more like:
1-2-3-3-3-2-2-1-1
The same amount of work is done, all three threads get processed, it's
just the order isnt the same. Most important i think is that the gui
doesnt hang no matter how many 'threads' are started, and to get this
operation the programmer doesnt have to do too much work in coding it.
Yes, there are limitations, but then it's a simple technique too.
I think some of the other Eu users were just thinking critically
in order to make sure the differences were well known ahead of time.
I think that's a good idea too. I dont want anybody thinking they
are getting real threads and then get disappointed after they download
and spend an hour fooling around with it because it's not appropriate
for their particular task.
QUOTE
I find Euphoria itself to have this "quality" - an elegant
simplicity.
END QUOTE
Yes, i was trying to maintain that simplicity while still achieving
certain goals i had for a few of my programs that i found needed to
stop hanging the gui when they did long operations. I first found
this technique to be useful a few years back when i was working on
a chess program in C where the 'computer' would have to 'think' for
long periods of time in a deep evaluation loop. I couldnt have the
user sitting there waiting for the computer to come up with a move
just to be able to take back their previous move, or worse yet,
move the window around :) Because of this, i didnt need to actually
compile with the multi threaded version. Interestingly, either way,
you get approximately the same overall behaviour once the program
is compiled.
I may create a true 'threading' task manager that allows parallel
'threads' to run just to see how the two compare for a few applications.
With this as well as with many other 'classes' used with my library,
the user will then have the choice what technique they wish to use
simply by including the appropriate include file...
Either "ThreadManager01.ew" or "ThreadManager02.ew". What the heck,
give users the choice right?
Kat:
QUOTE
How about "Kinda Almost Threads" ?
END QUOTE
Hee hee, yeah, i was joking with one of my replies when i said i could
stick in with the description of the file:
"Threads in mirror may appear bigger than they actually are."
:)
Thanks again for all the ideas/suggestions.
Take care,
Al
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
17. Re: Someone changed my Thread Manager writeup?
How about Nylon Manager.
Don Cole,
SF
18. Re: Someone changed my Thread Manager writeup?
> Date: Wed, 10 Aug 2005 20:10:28 -0500
> From: "Kat" <gertie at visionsix.com>
> Subject: Re: Someone changed my Thread Manager writeup?
>
>
> On 11 Aug 2005, at 10:58, David Jarvis wrote:
>
>
>>> You asked about a new name for the library. Perhaps "Software Pseudo
>>> Threads" ?
>>
>>>> >
>>>>> > > Ferlin Scarborough wrote:
>>>>
>>>>>> > > >
>>>>
>>>>> > > Sorry about that it should be Simultaneous Events Manager.
>
>
>>>> > Right now im thinking about "Thread Manager for Pseudo Threads",
>
>
> How about "Kinda Almost Threads" ?
>
>
>
> Kat
I definitely vote for this one!!! Rob? Go ahead, please....
CChris
19. Re: Someone changed my Thread Manager writeup?
On Wed, 10 Aug 2005 07:10:31 -0700, Matt Lewis
<guest at RapidEuphoria.com> wrote:
<snip>
I have to agree with Matt on this. The main thing I would say here is
that if Rob offers something like this in 2.6, I'll not be happy. I
certainly don't want him to start thinking that now Al Getz's "Thread
Manager" is in the archives, I don't have to bother.
>Al Getz wrote:
>BTW, what single word name would you use to describe these pseudo 'threads'?
"Background task manager", basically a time()-based wrapper around
doEvents() (or the WinClass equivalent). Multiple background tasks can
be started, but the last one started must complete before any previous
can resume. In particular, blocked I/O (still) stalls the entire app.
>It does in fact use:
>"Preemptive Multitasking"
>ie uses some criteria to decide how long any one task should run
>before giving another task a turn to use the operating system.
No, it does not. At best you might claim it is "Dualtasking", between
the top of the background task stack and the GUI message loop, but
*Multi* tasking is just downright misleading.
>I guess i could add a scheduling mechanism if that would make more
>people happy :)
I'd be very surprised if you could.
>I really think you should try a few applications using this kind of
>technique before you pass judgement.
I don't need to, since I already know how to call doEvents() )
>Note that if thread 2 is almost done when thread 3 is initiated,
>after thread 3 is complete thread 2 completes rather quickly
>because it's almost done.
Which begs the question: Why bother with a stack of time() values?
Why not just have a single atom?
Some other notes:
There should be a built-in single procedure call for:
if CheckThread() then
if QueryQuitMessage(0) then
end if
ContinueThread(TimeSlice)
end if
rather than having to code the whole of that in every task loop.
Here is the win32lib equivalent:
atom TimeSlice
atom EndSlice
global procedure StartThread(atom t)
TimeSlice = t
EndSlice=time()+TimeSlice
end procedure
global procedure CheckThread()
if time()>EndSlice then
EndSlice=time()+TimeSlice
doEvents(0)
end if
end procedure
Regards,
Pete
20. Re: Someone changed my Thread Manager writeup?
Pete Lomax wrote:
>
>
> Some other notes:
> There should be a built-in single procedure call for:
> }}}
<eucode>
> if CheckThread() then
> if QueryQuitMessage(0) then
> end if
> ContinueThread(TimeSlice)
> end if
> </eucode>
{{{
</font>
> rather than having to code the whole of that in every task loop.
>
I heartily agree. That would make this library useful. Here's how I'd
make it platform/library agnostic:
-- The real QueryQuit() is a function, but this requires a
-- procedure, so wrap the real thing here (users of other
-- libs may need to do the same):
constant QUERYQUIT = routine_id("QueryQuitMessage")
procedure query_quit_message()
if call_func( QUERYQUIT, {0}) then end if
end procedure
integer event_rid
sequence event_args
-- Set the default to use WinClass:
event_rid = routine_id("query_quit_message")
event_args = {}
-- You can make a procedure like this for any existing GUI lib
-- to make it easy:
global procedure useWin32Lib()
event_rid = routine_id("doEvents")
event_args = {0}
end procedure
-- Users can specify their own routine if they like:
global procedure useAny( integer rid, sequence args )
event_rid = rid
event_args = args
end procedure
global procedure CheckThread()
if time() > EndSlice then
call_proc( event_rid, event_args )
EndSlice = time() + TimeSlice
end if
end procedure
Matt Lewis
21. Re: Someone changed my Thread Manager writeup?
Pete Lomax wrote:
>
> On Wed, 10 Aug 2005 07:10:31 -0700, Matt Lewis
> <guest at RapidEuphoria.com> wrote:
>
> <snip>
> I have to agree with Matt on this. The main thing I would say here is
> that if Rob offers something like this in 2.6, I'll not be happy. I
> certainly don't want him to start thinking that now Al Getz's "Thread
> Manager" is in the archives, I don't have to bother.
>
> >Al Getz wrote:
> >BTW, what single word name would you use to describe these pseudo 'threads'?
> "Background task manager", basically a time()-based wrapper around
> doEvents() (or the WinClass equivalent). Multiple background tasks can
> be started, but the last one started must complete before any previous
> can resume. In particular, blocked I/O (still) stalls the entire app.
>
> >It does in fact use:
> >"Preemptive Multitasking"
> >ie uses some criteria to decide how long any one task should run
> >before giving another task a turn to use the operating system.
> No, it does not. At best you might claim it is "Dualtasking", between
> the top of the background task stack and the GUI message loop, but
> *Multi* tasking is just downright misleading.
>
> >I guess i could add a scheduling mechanism if that would make more
> >people happy :)
> I'd be very surprised if you could.
>
> >I really think you should try a few applications using this kind of
> >technique before you pass judgement.
> I don't need to, since I already know how to call doEvents() )
>
> >Note that if thread 2 is almost done when thread 3 is initiated,
> >after thread 3 is complete thread 2 completes rather quickly
> >because it's almost done.
> Which begs the question: Why bother with a stack of time() values?
> Why not just have a single atom?
>
> Some other notes:
> There should be a built-in single procedure call for:
> }}}
<eucode>
> if CheckThread() then
> if QueryQuitMessage(0) then
> end if
> ContinueThread(TimeSlice)
> end if
> <font color="#330033"></eucode>
{{{
</font>
> rather than having to code the whole of that in every task loop.
>
> Here is the win32lib equivalent:
> }}}
<eucode>
> atom TimeSlice
> atom EndSlice
>
> global procedure StartThread(atom t)
> TimeSlice = t
> EndSlice=time()+TimeSlice
> end procedure
>
> global procedure CheckThread()
> if time()>EndSlice then
> EndSlice=time()+TimeSlice
> doEvents(0)
> end if
> end procedure
> <font color="#330033"></eucode>
{{{
</font>
>
> Regards,
> Pete
>
>
Hello Pete,
Sorry, i just dont feel like arguing about this anymore.
It's in the archives -- download it and try it, or assume
you know what it does and dont.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
22. Re: Someone changed my Thread Manager writeup?
Hi again Pete,
Ok, that was the short reply :)
I guess it just pisses me off when some people give something about
three seconds of thought before they start rattling off bad points
about something. It's ok though i guess, as a critical look is
worthwhile.
Rob said he was working on threads so he's not going to stop now :)
I said it used preemptive MT because once the time slice is up
another thread can break in. preemptive MT doesnt imply an order.
If you dont like that, then call it pseudo preemptive MT'ing :)
>I guess i could add a scheduling mechanism if that would make more
> >people happy :)
> I'd be very surprised if you could.
What would be so surprising about that???
I kept saying in past posts that the operation is from a software
point of view it works like threads...from a hardware standpoint
(like I/O) the user still has to break up his task into pieces.
I also said the order or completion doesnt always matter:
OrderA:
Thread 1, Part A
Thread 2, Part A
Thread 1, Part B
Thread 2, Part A
OrderB:
Thread 1, Part A
Thread 2, Part A
Thread 2, Part B
Thread 1, Part A
Both take the same about of time (approx), and both complete
both tasks. Many times the user doesnt care what order they
are done in.
As i had mentioned, i can change this so that we would get OrderA
all the time, but it makes the code more complicated. Dont be
surprized because as you know this is all mostly software and you
can do almost anything with software :)
Also, as i mentioned time and time again in past posts, there are
going to be a ton of times when the user wont know the difference
anyway (OrderA or OrderB ?).
There's lots of things this doesnt do that 'real' threads can do,
such as wait for another thread to complete before continuing, but
that would add more code too. This addresses the most basic problems
that come up from not having any threads at all (at least until Rob
completes his task of adding some sort of threads to Eu).
Im using this now all the time, and i certainly wouldnt use it
if it didnt work, or didnt provide a decent amount of functionality
over not having it.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
23. Re: Someone changed my Thread Manager writeup?
Matt Lewis wrote:
>
> Pete Lomax wrote:
> >
> >
> > Some other notes:
> > There should be a built-in single procedure call for:
> > }}}
<eucode>
> > if CheckThread() then
> > if QueryQuitMessage(0) then
> > end if
> > ContinueThread(TimeSlice)
> > end if
> <font color="#330033">> </eucode>
{{{
</font></font>
> > rather than having to code the whole of that in every task loop.
> >
>
> I heartily agree. That would make this library useful. Here's how I'd
> make it platform/library agnostic:
> }}}
<eucode>
> -- The real QueryQuit() is a function, but this requires a
> -- procedure, so wrap the real thing here (users of other
> -- libs may need to do the same):
> constant QUERYQUIT = routine_id("QueryQuitMessage")
> procedure query_quit_message()
> if call_func( QUERYQUIT, {0}) then end if
> end procedure
>
> integer event_rid
> sequence event_args
>
> -- Set the default to use WinClass:
> event_rid = routine_id("query_quit_message")
> event_args = {}
>
> -- You can make a procedure like this for any existing GUI lib
> -- to make it easy:
> global procedure useWin32Lib()
> event_rid = routine_id("doEvents")
> event_args = {0}
> end procedure
>
> -- Users can specify their own routine if they like:
> global procedure useAny( integer rid, sequence args )
> event_rid = rid
> event_args = args
> end procedure
>
> global procedure CheckThread()
> if time() > EndSlice then
> call_proc( event_rid, event_args )
> EndSlice = time() + TimeSlice
> end if
> end procedure
> <font color="#330033"></eucode>
{{{
</font>
>
> Matt Lewis
>
Hi Matt,
This is basically my 2nd generation of coding this technique, so
while there may be a way to wrap CheckThread() a little neater,
it's still easier to use than the old way i used to do it.
Besides, there is a little more to this then 'threads' alone...
QueryQuitMessage(0) is simply taking a break to check messages,
but QueryQuitMessage(1) allows the app to quit (tasks that dont
have to complete before the app quits). If the caller uses
QueryQuitMessage(1) and they get a true return value then they
should exit the loop.
I guess this could be coded as
if CheckThread(1) then
exit
end if
which would make it a little neater i guess.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
24. Re: Someone changed my Thread Manager writeup?
Sorry, in that post about the orders the two orders should read:
OrderA:
Thread 1, Part A
Thread 2, Part A
Thread 1, Part B
Thread 2, Part B
OrderB:
Thread 1, Part A
Thread 2, Part A
Thread 2, Part B
Thread 1, Part B
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
25. Re: Someone changed my Thread Manager writeup?
Al Getz wrote:
>
> Hi again Pete,
>
> Ok, that was the short reply :)
> I guess it just pisses me off when some people give something about
> three seconds of thought before they start rattling off bad points
> about something.
<snip>
> I said it used preemptive MT because once the time slice is up
> another thread can break in. preemptive MT doesnt imply an order.
> If you dont like that, then call it pseudo preemptive MT'ing :)
Fine, but that's about the same reason why we are all saying that you're
wrong. This is cooperative multitasking, at best, though even that is
stretching things a little bit. Look at these links to see why everyone
keeps telling you that you're not doing preemptive multitasking:
http://en.wikipedia.org/wiki/Preemptive_multitasking
http://en.wikipedia.org/wiki/Co-operative_multitasking
> >I guess i could add a scheduling mechanism if that would make more
> > >people happy :)
> > I'd be very surprised if you could.
> What would be so surprising about that???
The way your code works now, there's not really a way to add on a generic
scheduling mechanism that would allow different threads to do work for
whatever timeslice they're given. The closest you could probably get would
be to set up some timers and use that as your scheduling mechanism. Or,
you'd end up with a langwar style scheduler, which seems to me would be
a very different beast than your current method of yielding to GUI/OS
events.
> There's lots of things this doesnt do that 'real' threads can do,
> such as wait for another thread to complete before continuing, but
> that would add more code too. This addresses the most basic problems
> that come up from not having any threads at all (at least until Rob
> completes his task of adding some sort of threads to Eu).
>
> Im using this now all the time, and i certainly wouldnt use it
> if it didnt work, or didnt provide a decent amount of functionality
> over not having it.
No one has said that it isn't a valid way to prevent a long running task
from blocking the GUI. In fact, we've all said that we do this all the
time, just without the explicit TimeSlice construct.
Matt Lewis
26. Re: Someone changed my Thread Manager writeup?
Matt Lewis wrote:
>
> Al Getz wrote:
> >
> > Hi again Pete,
> >
> > Ok, that was the short reply :)
> > I guess it just pisses me off when some people give something about
> > three seconds of thought before they start rattling off bad points
> > about something.
>
> <snip>
>
> > I said it used preemptive MT because once the time slice is up
> > another thread can break in. preemptive MT doesnt imply an order.
> > If you dont like that, then call it pseudo preemptive MT'ing :)
>
> Fine, but that's about the same reason why we are all saying that you're
> wrong. This is cooperative multitasking, at best, though even that is
> stretching things a little bit. Look at these links to see why everyone
> keeps telling you that you're not doing preemptive multitasking:
>
> <a
> href="http://en.wikipedia.org/wiki/Preemptive_multitasking">http://en.wikipedia.org/wiki/Preemptive_multitasking</a>
> <a
> href="http://en.wikipedia.org/wiki/Co-operative_multitasking">http://en.wikipedia.org/wiki/Co-operative_multitasking</a>
>
> > >I guess i could add a scheduling mechanism if that would make more
> > > >people happy :)
> > > I'd be very surprised if you could.
> > What would be so surprising about that???
>
> The way your code works now, there's not really a way to add on a generic
> scheduling mechanism that would allow different threads to do work for
> whatever timeslice they're given. The closest you could probably get would
> be to set up some timers and use that as your scheduling mechanism. Or,
> you'd end up with a langwar style scheduler, which seems to me would be
> a very different beast than your current method of yielding to GUI/OS
> events.
>
> > There's lots of things this doesnt do that 'real' threads can do,
> > such as wait for another thread to complete before continuing, but
> > that would add more code too. This addresses the most basic problems
> > that come up from not having any threads at all (at least until Rob
> > completes his task of adding some sort of threads to Eu).
> >
> > Im using this now all the time, and i certainly wouldnt use it
> > if it didnt work, or didnt provide a decent amount of functionality
> > over not having it.
>
> No one has said that it isn't a valid way to prevent a long running task
> from blocking the GUI. In fact, we've all said that we do this all the
> time, just without the explicit TimeSlice construct.
>
> Matt Lewis
>
Hi Matt,
Ok, no problem, let's call it pseudo cooperative multitasking then.
I guess i like calling it something like:
Last Invoked First Completed Multitasking.
Or better yet (hee hee)
Last Invoked First Ended (LIFE) :)
I guess the main point being that it is multitasking at some level,
even if the order of thread execution isnt what is probably normally
encountered.
To make the next release a little clearer, ill add notes like Rob did
to make SURE users wont think Euphoria gets OS threads by downloading
this 'library'.
I have an easier way in mind to add a generic scheduling mechanism,
but im hard pressed to find justification for doing this. Once you
have true multitasking built into the OS (Windows) and the app has
thread-like behaviour (ThreadManager or similar) i cant seem to find
any app that would benefit from changing the order from
last-invoked-first-completed
to somethat that allocates time slices normally and continues to
poll threads giving each only 100ms and then switching to the next.
As i was saying in a previous post, it seems that disk saves can
actually benefit from the order as it is now, but yeah, that's only
one single application. So, if you'd like to think up a few possible
apps that could benefit from the truer time slice scheduler (as most
people would probably expect to see) i'd be glad to hear them.
Now im thinking perhaps some game application where there are several
game pieces moving around the play field -- each piece could have it's
own time slice, and you'd want their tasks to complete one after the other.
Unless their objective was small, it would probably be better to use
true time sharing rather than the LIFE multitasking. Course if their
objective was made small, the order would appear the same anyway.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
