1. Task API
--0-645872172-1128049835=:36464
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I simply must have a way of determining what tasks are active. Ideally, I'd
like
b=task_active(i) when i is the task id and the return is a boolean
and
s=task_all_active() where the return is a list (pref sorted) of all active
tasks.
It is not possible to maintain an accurate list of active tasks; I can redefine
task_schedule and add the id to the active list, and redefine task_suspend and
task_kill to remove it from the list, but I have no way to remove a task from the
list when it dies by returning from the task procedure.
Why I want this is for the termination routine for ME. I want to define it as
its own task which will yield and not do any work until it is the only task
running. This could also be used in a genric task library. You have the list of
active tasks on hand internally, so implementation shouldn't be too difficult.
As an alternative, if you want to keep the interface the same while allowing
accurate lists of active tasks to be maintained, you could change the behavior or
a return from a task procedure--let it act like task_yield rather than
task_kill--unless the task had supended or killed itself, it would remain active
on the same schedule and the procedure would be called at its next turn with the
parmaters from task_create
--0-645872172-1128049835=:36464
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<DIV>
<DIV>I simply must have a way of determining what tasks are active.
Ideally, I'd like</DIV>
<DIV> </DIV>
<DIV>b=task_active(i) when i is the task id and the return is a boolean</DIV>
<DIV> </DIV>
<DIV>and</DIV>
<DIV> </DIV>
<DIV>s=task_all_active() where the return is a list (pref sorted) of
all active tasks.</DIV>
<DIV> </DIV>
<DIV>It is not possible to maintain an accurate list of active tasks; I can
redefine task_schedule and add the id to the active list, and redefine
task_suspend and task_kill to remove it from the list, but I have no way to
remove a task from the list when it dies by returning from the task
procedure.</DIV>
<DIV> </DIV>
<DIV>Why I want this is for the termination routine for ME. I want to define it
as its own task which will yield and not do any work until it is the only
task running. This could also be used in a genric task library. You have
the list of active tasks on hand internally, so implementation shouldn't be too
difficult.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>As an alternative, if you want to keep the interface the
same while allowing accurate lists of active tasks to be maintained, you
could change the behavior or a return from a task procedure--let it act like
task_yield rather than task_kill--unless the task had supended or killed itself,
it would remain active on the same schedule and the procedure would be called at
its next turn with the parmaters from task_create </DIV><!-- toctype =
X-unknown --><!-- toctype = text --><!-- text --><!-- END TOC --></DIV>
--0-645872172-1128049835=:36464--
2. Re: Task API
Michael Nelson wrote:
>
> --0-645872172-1128049835=:36464
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
>
> I simply must have a way of determining what tasks are active. Ideally, I'd
> like
>
> b=task_active(i) when i is the task id and the return is a boolean
>
> and
>
> s=task_all_active() where the return is a list (pref sorted) of all active
> tasks.
>
> It is not possible to maintain an accurate list of active tasks; I can
> redefine task_schedule
> and add the id to the active list, and redefine task_suspend and task_kill to
> remove
> it from the list, but I have no way to remove a task from the list when it
> dies by
> returning from the task procedure.
>
> Why I want this is for the termination routine for ME. I want to define it as
> its own
> task which will yield and not do any work until it is the only task running.
> This could
> also be used in a genric task library. You have the list of active tasks on
> hand internally,
> so implementation shouldn't be too difficult.
>
>
> As an alternative, if you want to keep the interface the same while allowing
> accurate
> lists of active tasks to be maintained, you could change the behavior or a
> return from
> a task procedure--let it act like task_yield rather than task_kill--unless the
> task
> had supended or killed itself, it would remain active on the same schedule and
> the
> procedure would be called at its next turn with the parmaters from task_create
>
>
>
> --0-645872172-1128049835=:36464
> Content-Type: text/html; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit
>
> <DIV>
> <DIV>I simply must have a way of determining what tasks are active. Ideally,
> I'd like</DIV>
> <DIV> </DIV>
> <DIV>b=task_active(i) when i is the task id and the return is a boolean</DIV>
> <DIV> </DIV>
> <DIV>and</DIV>
> <DIV> </DIV>
> <DIV>s=task_all_active() where the return is a list (pref sorted) of all
> active
> tasks.</DIV>
> <DIV> </DIV>
> <DIV>It is not possible to maintain an accurate list of active tasks; I can
> redefine task_schedule
> and add the id to the active list, and redefine task_suspend and task_kill to
> remove it from the
> list, but I have no way to remove a task from the list when it dies by
> returning from the task
> procedure.</DIV>
> <DIV> </DIV>
> <DIV>Why I want this is for the termination routine for ME. I want to define
> it as its own
> task which will yield and not do any work until it is the only task running.
> This could also
> be used in a genric task library. You have the list of active tasks on hand
> internally, so
> implementation shouldn't be too difficult.</DIV>
> <DIV> </DIV>
> <DIV> </DIV>
> <DIV>As an alternative, if you want to keep the interface the same while
> allowing accurate lists of active tasks
> to be maintained, you could change the behavior or a return from a task
> procedure--let it act like task_yield rather than task_kill--unless
> the task had supended or killed itself, it would remain active on the same
> schedule and the procedure would be called at its
> next turn with the parmaters from task_create </DIV><!-- toctype = X-unknown
> --><!-- toctype = text --><!--
> text --><!-- END TOC --></DIV>
> --0-645872172-1128049835=:36464--
>
>
Hi there Mike,
I had asked for those about a week ago, and Rob had said he would
almost certainly implement both very soon.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
3. Re: Task API
Michael Nelson wrote:
> I simply must have a way of determining what tasks are active.
> Ideally, I'd like
>
> b=task_active(i) when i is the task id and the return is a boolean
>
> and
>
> s=task_all_active()
> where the return is a list (pref sorted) of all active tasks.
I'm pretty sure I'm going to implement both of those (more or less).
I probably won't sort them by task id. You'll have to do that.
Would you like suspended tasks to be included in the list
of active tasks? Should task_active() distinguish between
suspended and normally-active tasks?
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Task API
Robert Craig wrote:
>I'm pretty sure I'm going to implement both of those (more or less).
>I probably won't sort them by task id. You'll have to do that.
>Would you like suspended tasks to be included in the list
>of active tasks? Should task_active() distinguish between
>suspended and normally-active tasks?
Thanks Rob. IMO this will make the API pretty complete while still very simple.
Sorting the list is not a priority. In both cases, suspended tasks should be
considered inactive and retern false or be excluded from the list. My answer is
not nessarily the correct one.
Perhaps task_active should be instead task_status, returning an integer
indicating active, suspended, or killed. Global task status constants could be
provided for use as return values.
Then task_all_active would become task_list(i) where the parameter might be a
active, suspended, or killed.
When the next release of the tasking interpreter comes out, I will develop a
library to automate saving and restoring state during task switching. Basically,
it would have a procedure task_link(i1,i2,i3) which would be passed the routine
id's of three procedures: the save procedure, the restore procedure, and the
termination procedure. The task lib would redefine task_yield to call the save
procedures in the order they are defined, then do the task switch, then call the
restore procedures in reverse order. A procedure would be provided
(task_terminate) to initiate program termination and all of the terminate
procedures would be called (the third id could be -1 if the particular library
calling task_link does not need a termination procedure). The task lib would use
crash_routine to invoke this automatically.
Added functionality would be task_lock to prohibit task swiching during
operations that need to be uninterrupted. Of course in your own code you will
simply not call task_yield until you are finshed, but this provides for the case
of calling a library routine which does call task_yield. A task_unlock procedure
would be provided to release the lock and reenable task switching. The task which
has the lock suspending or killing itself or returning from its task procedure
would also release the lock.
If you want to use any of these ideas in the interpreter or an official RDS lib,
feel free.
-- Mike
5. Re: Task API
Robert Craig wrote:
>
> Michael Nelson wrote:
> > I simply must have a way of determining what tasks are active.
> > Ideally, I'd like
> >
> > b=task_active(i) when i is the task id and the return is a boolean
> >
> > and
> >
> > s=task_all_active()
> > where the return is a list (pref sorted) of all active tasks.
>
> I'm pretty sure I'm going to implement both of those (more or less).
> I probably won't sort them by task id. You'll have to do that.
>
> Would you like suspended tasks to be included in the list
> of active tasks? Should task_active() distinguish between
> suspended and normally-active tasks?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Rob how about you make a task_list() that returns a 2 dimentional sequence. The
first having a list of active task IDs, and the second sequence having a list of
inactive (suspended) task IDs. This way, there would only need one routine vs
two.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
6. Re: Task API
Vincent wrote:
>
> Robert Craig wrote:
> >
> > Michael Nelson wrote:
> > > I simply must have a way of determining what tasks are active.
> > > Ideally, I'd like
> > >
> > > b=task_active(i) when i is the task id and the return is a boolean
> > >
> > > and
> > >
> > > s=task_all_active()
> > > where the return is a list (pref sorted) of all active tasks.
> >
> > I'm pretty sure I'm going to implement both of those (more or less).
> > I probably won't sort them by task id. You'll have to do that.
> >
> > Would you like suspended tasks to be included in the list
> > of active tasks? Should task_active() distinguish between
> > suspended and normally-active tasks?
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> >
>
> Rob how about you make a task_list() that returns a 2 dimentional sequence.
> The first
> having a list of active task IDs, and the second sequence having a list of
> inactive
> (suspended) task IDs. This way, there would only need one routine vs two.
>
>
> Regards,
> Vincent
>
> ----------------------------------------------
> ___ __________ ___
> /__/\ /__________\ |\ _\
> \::\'\ //::::::::::\\ |'|::|
> \::\'\ //:::_::::_:::\\ |'|::|
> \::\'\ //::/ |::| \::\\ |'|::|
> \::\'\ //::/ |::| \::\\|'|::|
> \::\'\__//::/ |::| \::\|'|::|
> \::\','/::/ |::| \::\\|::|
> \::\_/::/ |::| \::\|::|
> \::,::/ |::| \:::::|
> \___/ |__| \____|
>
> .``.
> ',,'
>
>
Hi Vincent,
I ended up doing that with my Win demo. The sequence has one
element per task, and if the task is active it has a 1 in that
slot. The sequence can then be checked for a particular task...
if task[1] then
puts(1,"task 1 is running")
end if
if task[2] then
puts(1,"task 2 is running")
end if
etc., etc.
With the source code however, we'd also might need a cross ref table to
tell us which sequence element goes with which task...
if task[taskids[1]] then
puts(1,"task 1 is running")
end if
if task[taskids[2]] then
puts(1,"task 2 is running")
end if
I have a preference for one level per sequence, so that it's faster
to check what you're looking for...if you're checking to see if it's
running task_run[1] or task_suspended[1] would be nice,
task[1][IS_RUNNING] or task[1][IS_SUSPENDED] is going to be slower
for libs that have to constantly check.
BTW, doing it 'manually' means you have to be careful to make sure
you set (and reset) the sequence element at the right times. Would be
better to re-wrap the function calls i guess.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
7. Re: Task API
- Posted by Robert Craig <rds at RapidEuphoria.com>
Sep 30, 2005
-
Last edited Oct 01, 2005
Vincent wrote:
> Rob how about you make a task_list() that returns a 2 dimentional sequence.
> The first
> having a list of active task IDs, and the second sequence having a list of
> inactive
> (suspended) task IDs. This way, there would only need one routine vs two.
A common situation would be that a task waits (tests then yields)
for one or more other tasks to all terminate. I want that to have
low overhead, so I'll probably have a routine that returns a list
of active or suspended tasks in a 1-d sequence,
and another low-overhead routine that returns the status of
any one task. Maybe it would return:
-1 the task has finished (doesn't exist)
0 the task is suspended
+1 the task is active
By the way, something needed by Language War,
and other games, is the ability to stop the scheduler's clock,
and restart it later. In LW for instance, the user is allowed
to freeze the game (to answer the phone etc.). When he resumes
the game a few minutes later, it's not good for all
real-time tasks to suddenly be ready to run.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Task API
- Posted by Vincent <darkvincentdude at yahoo.com>
Sep 30, 2005
-
Last edited Oct 01, 2005
Robert Craig wrote:
>
> Michael Nelson wrote:
> > I simply must have a way of determining what tasks are active.
> > Ideally, I'd like
> >
> > b=task_active(i) when i is the task id and the return is a boolean
> >
> > and
> >
> > s=task_all_active()
> > where the return is a list (pref sorted) of all active tasks.
>
> I'm pretty sure I'm going to implement both of those (more or less).
> I probably won't sort them by task id. You'll have to do that.
>
> Would you like suspended tasks to be included in the list
> of active tasks? Should task_active() distinguish between
> suspended and normally-active tasks?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
I did some more thinking, and now think that task_all_active() or
task_all_inactive() would be unneccessary internally.
If we had s = task_list() and i = task_status(t_id), we can just do something
like this to get the status of all the tasks running (besides the initial task):
sequence tasks
tasks = task_list()
global function task_all_status()
sequence status
status = {}
for i = 1 to length(tasks) do
status &= task_status(tasks[i])
end for
return status
end function
task_status() could return a numeric sequence with -1, 0, or 1 values.
-1 would represent the task doesnt exist or has been deleted.
0 would represent the task is inactive (suspended).
1 would represent the task is active set by task_schedule().
task_status(0) would always be 1 because that is the initial task that is always
running until program termination?
I created my own task_list() so I didnt have to "manually" keep track of created
or deleted tasks. My version stores routine identifers, and task identifers
alongside eachother in a sequence; it ignores the initial task identifer. I would
prefer if task_list() was internal though.
It seems Euphoria crashes when I try to redefine the tasking routines, so I
added an underslash at the end; Is that a bug Rob?:
-- task.e
sequence tCount
tCount = {}
global function task_create_(integer id, sequence args)
integer result
result = task_create(id, args)
tCount &= {id, result}
return result
end function
global procedure task_kill_(integer task)
atom t_ID_Loc
sequence copy
copy = {}
task_kill(task)
t_ID_Loc = find(task, tCount)
for i = 1 to length(tCount) do
if equal(i, t_ID_Loc-1) or equal(i, t_ID_Loc) then
else
copy &= tCount[i]
end if
end for
tCount = copy
end procedure
global function task_list()
sequence list
list = {}
for f = 2 to length(tCount) by 2 do
list &= tCount[f]
end for
return list
end function
Simple Example program:
-- ex ..\source\eu.ex Example.ex
include task.e
constant WAIT_KEY = 26
integer a1, b2, c3, d4
sequence data
procedure a()
end procedure
procedure b()
end procedure
procedure c()
end procedure
procedure d()
end procedure
--------------------------------------
a1 = task_create_(routine_id("a"), {})
b2 = task_create_(routine_id("b"), {})
c3 = task_create_(routine_id("c"), {})
d4 = task_create_(routine_id("d"), {})
? task_list()
data = task_list()
-- comment anyone of these to test
task_kill_(data[1])
task_kill_(data[2])
task_kill_(data[3])
task_kill_(data[4])
? task_list()
machine_proc(WAIT_KEY, 0)
Rob, why is it that I can use the same task ID's in task_kill() multiple times,
but the program doesnt abort with an invalid task ID error?
How come I can't terminate the main program with task_kill(0)? :P
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
9. Re: Task API
I think it would be cool if the new multitasking system also would
support writing of simulation programs. I don't know what this means
in detail, but maybe anyway almost the same things that are required
by games such as Language War?
Regards,
Juergen
10. Re: Task API
Juergen Luethje wrote:
>
> I think it would be cool if the new multitasking system also would
> support writing of simulation programs. I don't know what this means
> in detail, but maybe anyway almost the same things that are required
> by games such as Language War?
>
> Regards,
> Juergen
>
Eh? That can be done with no problem with cooperative tasking. It will be even
easier with the next preview release, with three new routines: task_status(),
task_list(), and perhaps task_reset()?. I'm interested to see what Robert comes
up with for a scheduler stoping & restarting routine.
Regards,
Vincent
11. Re: Task API
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Oct 01, 2005
-
Last edited Oct 02, 2005
Vincent wrote:
> Juergen Luethje wrote:
>>
>> I think it would be cool if the new multitasking system also would
>> support writing of simulation programs. I don't know what this means
>> in detail, but maybe anyway almost the same things that are required
>> by games such as Language War?
>
>
> Eh? That can be done with no problem with cooperative tasking.
I was not meaning cooperative multitasking in general, but the concrete
new multitasking system that will be implemented in the next Euphoria
version. If the system, as it currently is, is good for writing of
simulation programs, then it's fine. If not, then my suggestion is to
improve it, so that it is suitable for that job.
Regards,
Juergen
--
Have you read a good program lately?
12. Re: Task API
- Posted by Vincent <darkvincentdude at yahoo.com>
Oct 01, 2005
-
Last edited Oct 02, 2005
Robert Craig wrote:
>
> A common situation would be that a task waits (tests then yields)
> for one or more other tasks to all terminate. I want that to have
> low overhead, so I'll probably have a routine that returns a list
> of active or suspended tasks in a 1-d sequence,
> and another low-overhead routine that returns the status of
> any one task. Maybe it would return:
> -1 the task has finished (doesn't exist)
> 0 the task is suspended
> +1 the task is active
That is an even better idea, and I can still make a task_list_all() routine:
global function task_list_all()
return {{task_list(0)} & {task_list(1)}}
end function
> By the way, something needed by Language War,
> and other games, is the ability to stop the scheduler's clock,
> and restart it later. In LW for instance, the user is allowed
> to freeze the game (to answer the phone etc.). When he resumes
> the game a few minutes later, it's not good for all
> real-time tasks to suddenly be ready to run.
Would this be another routine or two? Perhaps something like task_reset() and/or
task_stop()?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Regards,
Vincent
13. Re: Task API
- Posted by Robert Craig <rds at RapidEuphoria.com>
Oct 01, 2005
-
Last edited Oct 02, 2005
Vincent wrote:
> > By the way, something needed by Language War,
> > and other games, is the ability to stop the scheduler's clock,
> > and restart it later. In LW for instance, the user is allowed
> > to freeze the game (to answer the phone etc.). When he resumes
> > the game a few minutes later, it's not good for all
> > real-time tasks to suddenly be ready to run.
>
> Would this be another routine or two? Perhaps something like task_reset()
> and/or task_stop()?
>
> >
> > Regards,
> > Rob Craig
I haven't decided.
It could be two calls like: task_clock_stop() ... task_clock_resume()
Or it could be one call: task_clock_shift(atom seconds)
where the application would keep track of how many
seconds went by while the user was on the phone,
and tell me to shift the scheduler's clock accordingly.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
14. Re: Task API
Robert Craig wrote:
>
> I haven't decided.
> It could be two calls like: task_clock_stop() ... task_clock_resume()
> Or it could be one call: task_clock_shift(atom seconds)
> where the application would keep track of how many
> seconds went by while the user was on the phone,
> and tell me to shift the scheduler's clock accordingly.
>
Well in the regular Language War game, you use the second method. The game seems
to run fine with or without it though. Why is "bad" not having it?
What is task_clock_shift(atom seconds) suppost to do? Is it suppost to
re-schedule all the suspended & active "real-time" tasks when the program
resumes?
I made a routine:
global function task_schedule_(integer i, object x)
task_schedule(i, x)
? x -- remove this
return x
end function
global procedure task_shift_times(object SchedArgs, atom seconds)
sequence tasks
tasks = task_list() -- defined in task.e
for i = 1 to length(tasks) do
if length(SchedArgs[i]) = 2 then
ignore(task_schedule_(tasks[i], {
SchedArgs[i][1] + seconds,
SchedArgs[i][2] + seconds}))
end if
end for
end procedure
I also made an example program that waits for the user to press 'q', and counts
how long the program has been waiting.
Output:
-----------------------------------
Original task_schedule() arguments:
Task 1: {1,3}
Task 2: {4,6}
Task 3: {7,9}
Press 'q' to resume
Seconds waited: 12.85
New task_schedule() arguments:
Task 1: {13.85,15.85}
Task 2: {16.85,18.85}
Task 3: {19.85,21.85}
-----------------------------------
Is that what it's suppost to do?
Does this apply to time-shared tasks too?
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
15. Re: Task API
- Posted by Robert Craig <rds at RapidEuphoria.com>
Oct 02, 2005
-
Last edited Oct 03, 2005
Vincent wrote:
> Robert Craig wrote:
> > I haven't decided.
> > It could be two calls like: task_clock_stop() ... task_clock_resume()
> > Or it could be one call: task_clock_shift(atom seconds)
> > where the application would keep track of how many
> > seconds went by while the user was on the phone,
> > and tell me to shift the scheduler's clock accordingly.
> >
> Well in the regular Language War game, you use the second method. The game
> seems to
> run fine with or without it though. Why is "bad" not having it?
For most of the tasks in LW it doesn't really matter.
I just noticed that the BASIC truce change will probably
occur immediately when you resume. Normally it takes a couple of
minutes between truce/hostile/cloaking changes.
> What is task_clock_shift(atom seconds) suppost to do? Is it suppost to
> re-schedule all
> the suspended & active "real-time" tasks when the program resumes?
It should keep the min/max increments the same, but shift the
min/max absolute start times ahead for all real-time (only) tasks,
to compensate for the time that the program (game) was suspended.
There's no need to adjust suspended tasks.
(Alternatively, the time() function could be shifted backwards.)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Task API
Robert Craig wrote:
> It should keep the min/max increments the same, but shift the
> min/max absolute start times ahead for all real-time (only) tasks,
> to compensate for the time that the program (game) was suspended.
> There's no need to adjust suspended tasks.
> (Alternatively, the time() function could be shifted backwards.)
Thats what I thought, thanks for helping me understand completely.
My library version of that routine works with no problem then if we had a
task_list(b) routine, which could also be written with only task_status(id).
I guess what you decide on implementing for the next preview release will
determind whether or not I submit my task routines to the archive. Either way,
I'm diligently waiting for the next preview release.
BTW, don't forget to fix that bug Michael Nelson mentioned.
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
17. Re: Task API
I somewhat prefer task_shift(atom seconds) as the means of handling
pauses: at essentially no extra cost, it could take a negative argument
to cause real time tasks to run sooner. This could be useful in games
and sims when things are slow at the moment and the user wants to move
things along.
-- Mike Nelson
18. Re: Task API
Robert Craig wrote:
>
> Vincent wrote:
> > > By the way, something needed by Language War,
> > > and other games, is the ability to stop the scheduler's clock,
> > > and restart it later. In LW for instance, the user is allowed
> > > to freeze the game (to answer the phone etc.). When he resumes
> > > the game a few minutes later, it's not good for all
> > > real-time tasks to suddenly be ready to run.
> >
> > Would this be another routine or two? Perhaps something like task_reset()
> > and/or task_stop()?
> >
> > >
> > > Regards,
> > > Rob Craig
>
> I haven't decided.
> It could be two calls like: task_clock_stop() ... task_clock_resume()
> Or it could be one call: task_clock_shift(atom seconds)
> where the application would keep track of how many
> seconds went by while the user was on the phone,
> and tell me to shift the scheduler's clock accordingly.
I'd prefer the former. If that's chosen, then later it would
be pretty easy to add other things, like have the game clock speed
adjusted. This would give an easy way to the programmer to cater
to novice users, general slow-motion, testing, etc.
(Shifting the clock sounds dangerous! Without stop_clock still
implemented one would risk a time period "happening twice". So
that's even more reason to forget the latter alternative.)
-- Another Euphoric, since Nov. 18, 2004 --
