Re: Multitasking 2 Problem
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
>
> ----------------------------------------------
>
>
http://members.aol.com/chriscrylex/euphoria.htm
http://uboard.proboards32.com/
http://members.aol.com/chriscrylex/EUSQLite/eusql.html
|
Not Categorized, Please Help
|
|
