Re: Multitasking 2 Problem
Chris Burch wrote:
>
> Vincent wrote:
> >
> > Robert Craig wrote:
> > >
> > > Al Getz wrote:
> > > > My second question is, why do the tasks have to be created over
> > > > again after they 'end' normally? Why cant the task id's be
> > > > persistent until the user removes (or kills or whatever) the task?
> > > > The reason for asking this is mainly because a "task" will be
> > > > a routine (with a routine id) that will remain part of the program
> > > > until the process ends, so it would make sense that if it was
> > > > declared as a task that it would normally be used as a task until
> > > > the program ends. The only thing that needs to change is if it
> > > > is active or not, ie if it should be called or not which i guess
> > > > would be done with task_schedule(). If the task ends there's really
> > > > no reason to have to change the id is there? Even with 50 tasks in
> > > > a program that would only mean 50 id's issued and that would be that.
> > > > If a task 'ended' it would be taken off the active list. This would
> > > > also mean there could never be confusion about a task id belonging
> > > > to one task or another because an id would last till programs end,
> > > > just like a routine_id.
> > >
> > > I'm not sure if you understand that a task is not a routine,
> > > and a routine is not a task. A program has a fixed number
> > > of routines, but you can dynamically create 1000
> > > or 1 million tasks that all run the same (say) quick sort routine
> > > at the same time, but using different private data, a different
> > > call stack, and a different "next statement to execute".
> > > Each of those (potentially) millions of tasks needs its own task id.
> > > That task id should not be recycled immediately because another
> > > task might be monitoring the status of that task, and might
> > > not check the status until long after the first task is dead and gone.
> > > If another task were assigned the same id, it could be confusing.
> > >
> > > If you look at Language War, it has maybe a dozen "fixed" tasks that
> > > are created near the beginning of the game, and never die.
> > > Most of them do something like:
> > > }}}
<eucode>
> > > global procedure task_life()
> > > -- independent task: update "life support" energy
> > > while TRUE do
> > > if shuttle then
> > > p_energy(-3)
> > > else
> > > p_energy(-13)
> > > end if
> > > task_yield()
> > > end while
> > > end procedure
> > > </eucode>
{{{
> > >
> > > The infinite while loop prevents this task from ever
> > > reaching the end and terminating. It can only be terminated
> > > if another task kills it, or the whole program ends.
> > > Only one task id is needed.
> > >
> > > There are other cases in LW where an infinite-loop task can
> > > be suspended and later rescheduled by other tasks, as need be,
> > > but it never runs off the end or returns. Maybe that's
> > > what you are looking for.
> > >
> > > Language War also has tasks that are created, do their thing,
> > > and then die, so the task id numbers do creep up indefinitely
> > > as the game progresses. e.g. each phasor that's drawn is
> > > a separate task that uses up a task id number. If you play a game of
> > > Language War for 1000 trillion years, the id numbers might roll over.
> > > Actually, a few days ago, as a test, I changed the 1e14 roll over
> > > point to something like 20 or 30, and Language War ran fine. It wrapped
> > > numerous times, but I don't have tasks that check the status of other
> > > tasks. Most tasks are very independent of each other, or
> > > else they check global variables to see what has happened so far.
> > >
> > > Regards,
> > > Rob Craig
> > > Rapid Deployment Software
> > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> > >
> >
> > I tested Language War with a task limit of 5. The game ran, but not properly
> > (C rules the galaxy one second within game play) as there is 10-15 tasks
> > running
> > in the game. If I lowered it to 2, the game would run until I press a key,
> > then
> > terminate abrupty; but it didnt crash with an error or freeze, which is
> > good.
> >
> > So basically once the limit is hit, your program may stop working normally,
> > but it should not lock up or crash.
> >
> > Fortuantly, the new "theoretical" limit is 9e15 or 9000 trillion tasks! That
> > means you are never going have to worry about reaching the limit. First of
> > all
> > Euphoria will likely crash far before that limit could ever reached, second,
> > your program would begin to run so slow that you could mistake it for a
> > crash...
> > a powerful super computer would be neccessary to run an Euphoria program
> > with
> > billions or trillions of tasks running,let alone 9000 trillion.
> >
> > I dont really see a need for more than a few hundred tasks in any typical
> > appilication,
> > unless maybe if it was a web server. But nevertheless, it's good piece of
> > mind
> > to know that its virtually unlimited. 
> >
> >
> > Regards,
> > Vincent
>
> 
>
> The first PC that I had access to was a 286 with 640K ram, and a 40 MB (
> repeat
> MB) hard drive - it was said to be impossible to ever be able to fill that up.
> (and numerous other examples)
>
> I wonder how many tasks the Enterprise holodecks will use simultaneously?
>
> Heh heh
>
> Chris
>
>
> > ----------------------------------------------
> >
> >
<snip>
Hi Chris,
Yeah that's cute, but you're right in that it's a valid point.
One of my old computers file system date only went up to
something like Dec, 1987, and i had quite a job rewriting part of the
operating system to get it to save files with a higher year, especially
because the orig op sys only allocated 3 bits for the year on disk!
That taught me a lesson in not hard coding limits whenever possible.
There might be a way around Rob's dilemma...just takes a little thought.
How to assign task id's without running out of id's?
Maybe go to a 64 bit large integer (something like a million million million)?
Easy to implement in Eu but will add a slight increase in delay time.
There's no way in jell a program can issue 18446744073709551616 tasks i bet
he he :) Then again, 1e14 isnt bad either.
I could easily see a big math package issuing lots and lots of task ids,
but probably not more than one every half second as the user keeps repeating
some math operation. It would take a LONG time to use up all the ids.
Even so, i prefer a method that has no limit.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
|
Not Categorized, Please Help
|
|
