OpenEuphoria

Re: Multitasking 2 Problem

• Posted by Vincent <darkvincentdude at yahoo.com> Oct 21, 2005
• 615 views

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

----------------------------------------------
     ___	      __________      ___
    /__/\            /__________\    |\ _\
    \::\'\          //::::::::::\\   |'|::|
     \::\'\        //:::_::::_:::\\  |'|::|
      \::\'\      //::/  |::|  \::\\ |'|::|
       \::\'\    //::/   |::|   \::\\|'|::|
        \::\'\__//::/    |::|    \::\|'|::|
         \::\','/::/     |::|     \::\\|::|
          \::\_/::/      |::|      \::\|::|
           \::,::/       |::|       \:::::|
            \___/        |__|        \____|

 	                 .``.
		         ',,'