Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!caen!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: General questions regarding Tasks
Message-ID: <1991May24.120133.31035@kuhub.cc.ukans.edu>
Date: 24 May 91 17:01:33 GMT
References: <1991May24.160440.374@m.cs.uiuc.edu>
Organization: University of Kansas Academic Computing Services
Lines: 74

In article <1991May24.160440.374@m.cs.uiuc.edu>, schwager@m.cs.uiuc.edu (Michael Schwager) writes:
> 
> Hi,
> I'm looking for guidelines about using tasks within C programs.  C code
> examples would help.  I've got Aztec C 5.0d, and their little beep.c
> example only goes so far.  For example, I wonder: Can I call other
> functions from within my task?

Yes, you can call other functions and access global variables.  If
using base-relative addressing, do a geta4(); at the beginning of your
task code.  Also, stack checking should be off in any module that has
code that will get run in the context of a sub-task.

>  What do I need to be careful of (besides changing system variables)?

Don't call DOS!!!  This also means don't call things like
OpenLibrary() unless you know the library is in memory.  Many DOS
functions that used to let you get away with being a task in 1.3 will
barf in 2.0.  So don't call DOS or only OpenXXX call that could
require something to be loaded off the disk.  If you do need access to
such devices or libs, have the parent open it first to load it, and
hold it open, then when the child opens it, it will be in memory.

>  Also, can I pass variables to a Task, like this:
>      CreateTask ("Name", 0, func3 (var0, var1, var2), BIGSTACK);

Not normally.  Create just just creates the task struct, allocates the
stack, and jumps to the beginning PC.  Parameters are before
offset to the stack base, so they contain garbage.  If you manually
create a task and add it with AddTask(), you could fudge the stack and
put a dummy parameter list at the base of the stack.  Since the task
code allocates the auto variables, all local variables are okay (of
course static variables are still that).
  
> I'm getting random (I think) address error Guru's when I try to get too
> fancy with Tasks.  Too fancy means: I want to call another function from
> within it.

Hmmm, this should work.  It works fine for me under SAS with both PC
rel and 32 bit abs function jumps.
 
> func3 ()  /* It's a task! */
> {
>      blah;
>      func1 (number);   /* Oooo.can I do this? Say func1() only has automagic
>      	       	    variables.  */

No, this is okays long as you have enough stack.  The code in func3()
will allocate and clean up the parameters on the stack.  Code in
func1() at begin and end will allocate and cleanup auto variables
(usually via LINK and UNLINK).

>      blah;

Zapp.  If I read this right your task is running right off the end.
If it does this it hits a return.  Return to where?  There isn't a
valid address, so it RETs into space.

A task function should be an endless loop with some kind of check for
an exit condition.  Since RemTask(called by DeleteTask) can be picky
about conditions, it should call Wait(0L) (wait forever) to put itself
in a safe state to be deleted by the parent.  Alternately a task can
RemTask(0L) itself, but this doesn't clean up the allocations for the
stack and TCB.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  mgooderum	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~