1. Task API question
Rob,
I have also noted that when the end of the top level code is reached the
program terminated even if there are other task active besides task 0.
Is this the desired behavior? Task 0 can be killed or suspended without
terminating the program, should the code for opRETURNT be modified to
check for other active tasks?
I could argue the case either way and I can program around if quite
easily with my new lib.
-- Mike Nelson
2. Re: Task API question
Michael Nelson wrote:
> I have also noted that when the end of the top level code is reached the
> program terminated even if there are other task active besides task 0.
> Is this the desired behavior? Task 0 can be killed or suspended without
> terminating the program, should the code for opRETURNT be modified to
> check for other active tasks?
>
> I could argue the case either way and I can program around if quite
> easily with my new lib.
It's a good point.
If the top-level code reaches the end, I think it will be
more convenient for most people if the whole program
simply ends at that point. It will be the same effect as
executing an abort(). In the code I've worked with, you might
have some dangling tasks, some of which are actually infinite
tasks that wait for work to be given to them. It might
be a bit of a bother for the top-level task to have to
go through all these tasks and kill them. People might frequently
forget to do this, and then be surprised that their program
is "hanging" indefinitely (due to a task that has not died).
If the top-level task does need to let some other tasks finish,
it could check their status, or perhaps some global variables,
and not terminate until they are all done.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Task API question
Rob,
I think you are right, the current behavior is better. When the contrary
behavior is needed, some simple code at the end of the top level will
keep the top level code from ending. For example:
while 1 do
task_kill(0)
task_yield()
end while
the infinite loop prevents the opRETURNT from executing, but killing
task 0 stops the loop after 1 iteration.
-- Mike Nelson
Robert Craig wrote:
>
>
>posted by: Robert Craig <rds at RapidEuphoria.com>
>
>Michael Nelson wrote:
>
>
>>I have also noted that when the end of the top level code is reached the
>>program terminated even if there are other task active besides task 0.
>>Is this the desired behavior? Task 0 can be killed or suspended without
>>terminating the program, should the code for opRETURNT be modified to
>>check for other active tasks?
>>
>>I could argue the case either way and I can program around if quite
>>easily with my new lib.
>>
>>
>It's a good point.
>If the top-level code reaches the end, I think it will be
>more convenient for most people if the whole program
>simply ends at that point. It will be the same effect as
>executing an abort(). In the code I've worked with, you might
>have some dangling tasks, some of which are actually infinite
>tasks that wait for work to be given to them. It might
>be a bit of a bother for the top-level task to have to
>go through all these tasks and kill them. People might frequently
>forget to do this, and then be surprised that their program
>is "hanging" indefinitely (due to a task that has not died).
>If the top-level task does need to let some other tasks finish,
>it could check their status, or perhaps some global variables,
>and not terminate until they are all done.
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
>
>
4. Re: Task API question
Actually
task_kill(0)
task_yield()
without the loop is sufficient to to prevent the top level code from ending.
-- Mike
Michael Nelson wrote:
>
> Rob,
>
> I think you are right, the current behavior is better. When the
> contrary behavior is needed, some simple code at the end of the top
> level will keep the top level code from ending. For example:
>
> while 1 do
> task_kill(0)
> task_yield()
> end while
>
> the infinite loop prevents the opRETURNT from executing, but killing
> task 0 stops the loop after 1 iteration.
>
> -- Mike Nelson
>
> Robert Craig wrote:
>
>>
>> posted by: Robert Craig <rds at RapidEuphoria.com>
>>
>> Michael Nelson wrote:
>>
>>
>>> I have also noted that when the end of the top level code is reached
>>> the program terminated even if there are other task active besides
>>> task 0. Is this the desired behavior? Task 0 can be killed or
>>> suspended without terminating the program, should the code for
>>> opRETURNT be modified to check for other active tasks?
>>>
>>> I could argue the case either way and I can program around if quite
>>> easily with my new lib.
>>>
>>
>> It's a good point.
>> If the top-level code reaches the end, I think it will be
>> more convenient for most people if the whole program simply ends at
>> that point. It will be the same effect as executing an abort(). In
>> the code I've worked with, you might
>> have some dangling tasks, some of which are actually infinite
>> tasks that wait for work to be given to them. It might
>> be a bit of a bother for the top-level task to have to
>> go through all these tasks and kill them. People might frequently
>> forget to do this, and then be surprised that their program
>> is "hanging" indefinitely (due to a task that has not died).
>> If the top-level task does need to let some other tasks finish,
>> it could check their status, or perhaps some global variables, and
>> not terminate until they are all done.
>>
>> Regards,
>> Rob Craig
>> Rapid Deployment Software
>> http://www.RapidEuphoria.com
>>
>>
>
>
>
5. Re: Task API question
Michael Nelson wrote:
>
> Actually
>
> task_kill(0)
> task_yield()
>
> without the loop is sufficient to to prevent the top level code from ending.
Yes, and it makes me think that if the scheduler finds that no
tasks are active, i.e. no task can ever run again, then
instead of issuing a fatal error like I do now, I should
just abort(0) the program at that point. I had been concerned
that this situation might happen sort of accidentally, and
the programmer would be puzzled about why his program ended,
but now I think he will probably understand what happened,
especially since he must have killed task 0 at some point.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
