OpenEuphoria

2. Re: Multitasking 2 Problem

• Posted by Robert Craig <rds at RapidEuphoria.com> Oct 20, 2005
• 632 views

Al Getz wrote:
> After trying the new release i noticed that the task id numbers keep
> rising, even for the same task, when the task is created a second or
> more times...
> 
>   taskid=task_create(..)
> 
> creates say taskid=1, then after the task ends normally if it is
> created a second time taskid=2, then after that ends a third time
> produces taskid=3, etc.

Yes. You can create thousands of tasks that all simultaneously
run the same routine. These are all different tasks with different
task id's.

> I dont have any problem with using different numbers each time, but
> because they are continuously rising this means eventually the task id
> could reach max integer and the next create would cause a crash?
> Unless of course at some limit the numbers start over again?

When the task id reaches 1e14 (much bigger than an integer), 
I start over at 1 again, being careful not to issue the 
same id as one that is still in use. Task id's are atoms, 
not just integers. Somewhere beyond 1e14 is the point where 
adding 1 to a number gives you the same number.

To be squeaky clean, and avoid ever recycling ids, I considered 
making task id's sequences, which would slowly grow in length, 
so after reaching 1e14 I could just add another element to the 
sequence and start over. This would really make it unnecessary 
to ever recycle ids. However I often have to compare task id's 
against an internal list, and atoms would be faster. Probably no 
one will ever exceed 1e14, and if you do, recycling will happen, 
not a crash. The only theoretical problem is if you are  
checking the status of a task that died and had its id recycled
into a new task. You might think the original task was still running.

Given a machine 1000x faster than the PC's we have today, you might
be able to create 1e9 tasks per second if you did little else.
Then it would take 1e5 seconds (more than a day) to reach the 
point where recycling starts. I just tested now. I can increase 
the limit from 1e14 to 9e15. That's 90x more capacity. You'd need more
than 3 months. I guess I'll do that. (There's no point in 
performing arithmetic on a task id. It's just an identifier.)
On Linux/Unix etc. I think they start recycling process id's at
65000 or so.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

4. Re: Multitasking 2 Problem

• Posted by Vincent <darkvincentdude at yahoo.com> Oct 20, 2005
• 622 views

don cole wrote:
> 
> When running langwars in  Cooperative Multitasking Preview Release #2   .
> 
> 
> I get task_schedule() has not been declared.
> 
> I can't find it in any of the included files.
> 
> Don Cole
> SF
> 

Hi Don,

You have to use the batch file: lw.bat. Just clicking on the lw.ex isnt going to
work because the file type is associated with ex.exe, which does not have the
multitasking API.

In execute.e, you might want to change the constant TASK_ID_MAX from 1e14 to
9e15 for 90x more IDs to use before recycling occurs and routines start back to
1. You would think it would be ok to use the maximum atom value: 1e300, but
number accuracy in Euphoria is only good to about 15 digits, accuracy. Obviously
accuracy is important for keeping track of ID numbers.


Regards,
Vincent

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

 	                 .``.
		         ',,'

6. Re: Multitasking 2 Problem

• Posted by don cole <doncole at pacbell.net> Oct 20, 2005
• 612 views
• Last edited Oct 21, 2005

Vincent wrote:

> > 
> 
> Hi Don,
> 
> You have to use the batch file: lw.bat. Just clicking on the lw.ex isnt going
> to work because the file type is associated with ex.exe, which does not have
> the multitasking API.
> 
> In execute.e, you might want to change the constant TASK_ID_MAX from 1e14 to
> 9e15 for 90x more IDs to use before recycling occurs and routines start back
> to 1. You would think it would be ok to use the maximum atom value: 1e300, but
> number accuracy in Euphoria is only good to about 15 digits, accuracy.
> Obviously
> accuracy is important for keeping track of ID numbers.
> 
> 
> Regards,
> Vincent

Thank you Vince,

I wrote a program with Win32lib that:

Opens a window with a FIND EditText.

OnOpen loads in six lengthy data bases. (a lot of time)

SetHandle EditText to routine_id("search")

I would like the EditText to start taking entries and searching

before all the data bases are loaded. I only need the first three data basses

to start searching. To make this a little clearer the databases are movies.

OpenReg, OpenAdult, OpenDvd, SoldReg, SoldAdult, SoldDvd.

I would normally start out looking for open movies first then sold movies if 

nothing found in open.

Would this multitask make this go faster or at least appear to go faster?

Don Cole
SF



ope

8. Re: Multitasking 2 Problem

• Posted by Robert Craig <rds at RapidEuphoria.com> Oct 21, 2005
• 613 views

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:

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

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
   http://www.RapidEuphoria.com

10. Re: Multitasking 2 Problem

• Posted by Al Getz <Xaxo at aol.com> Oct 21, 2005
• 599 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>
> 

Hello again,

Ok that makes sense, so i guess that wont be a problem then.
I guess it wont hurt to let the task end and then create it again 
later if needed so i guess i'll leave my programs working that way.


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"

12. Re: Multitasking 2 Problem

• Posted by Al Getz <Xaxo at aol.com> Oct 21, 2005
• 597 views

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"

14. Re: Multitasking 2 Problem

• Posted by "Juergen Luethje" <j.lue at gmx.de> Oct 21, 2005
• 694 views

Al Getz wrote:

<big snip>

> It would take a LONG time to use up all the ids.

Yes. *Very* long. Rob had explained it in detail.

> Even so, i prefer a method that has no limit.

Several things in the world *are* limited. HE just did not and will not
ask us, whether or not we like this fact. 

Regards,
   Juergen

-- 
Have you read a good program lately?