Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!hplabs!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: Spawning tasks which draw . . .
Message-ID: <4793@well.UUCP>
Date: 21 Dec 87 00:28:35 GMT
References: <8712081929.AA17657@cory.Berkeley.EDU> <4696@well.UUCP> <554@oscvax.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: Network 23
Lines: 56
Summary: This is why you Forbid()....

In article <554@oscvax.UUCP> flynn@oscvax.UUCP (Flynn D. Fishman) writes:
>In article <4696@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>		PARENT				CHILD
>>	Parent sends kill signal to
>>	 child.
>>	Parent waits for reply.
>>					Child receives kill signal.
>>					Child cleans up anything it
>>					 allocated.
>>					Child Forbid()s.
>					^^^^^^^^^^^^^^^^
>>					Child replies signal.
>>					Child waits for Godot (Wait (0L)).
>>	Parent receives reply.
>>	Parent RemTask()s child.
>
>My question is this, why should the Child Forbid(), and who does the
>Permit() is that Automatic.  I do not see any reason why the Child should
>Forbid() since the parent is locked waiting for a reply anyways.
>
	The Permit() is implicit when you Wait() for Godot (#define GODOT
0L), or when you exit.

	Consider the following scenario.  You are the parent.  You spawn a
child process with a priority lower than your own.  While you (the parent)
are waiting for events, the child gets to run.  Eventually, you wish to kill
off the child.  So you send a pre-arranged signal to the child and wait for
the reply signal.

	The child cleans up, Forbid()s, replys the signal, and then either
Wait()s or exits.  By calling Forbid(), the child prevents the parent from
waking up immediately on the signal.  If the Forbid() weren't there, the
child would get pre-empted the instant it sent the signal off, and the
parent would wake up and blissfully remove the child task before it had
truly finished executing.

>On another note (c minor) if I spawn my
>task as indicated before, (using only local variables) and the mainline
>goes bye bye, does my system guru and start spouting smoke or does the
>memory used by my task still exist? (I vote for the guru but I
>have not had time to check and see)
>
	You have cast your ballot correctly.  Since your child task is part
of the parent's executable image, the DOS can't tell the difference when your
parent exits, and will unload both of you.  You will Guru either immediately
or when the next program overlays the memory you're running out of.  The
latter case will be much more difficult to track down as a bug.

	Moral:  Unless your subtask was LoadSeg()d, terminate all your
children before you terminate yourself.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor