Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!rochester!ur-tut!dpvc
From: dpvc@ur-tut (Davide P. Cervone)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Launching new Tasks in C
Message-ID: <2261@ur-tut.UUCP>
Date: 7 Jul 88 16:54:26 GMT
References:  <11752@agate.BERKELEY.EDU>
Reply-To: dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone)
Organization: Univ. of Rochester Computing Center
Lines: 46

In article <11752@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) writes:
>  There's a major problem with child tasks in that their code is normally
>  loaded as part of the main program, so you don't have much flexibility to
>  change things at load time or later.  On the other hand, if for some
>  reason you wanted to invoke one module process from inside another, this
>  is pretty easy: simplest is to use the AmigaDOS call
>
>         Execute("run module")
>
>  (You would have to use "run" so you would come back to your invoking
>  module immediately.)  You might LoadSeg() and CreateProc() instead, but I
>  don't see much advantage in that.

Well, I can think of a couple reasons why LoadSeg() and CreateProc() might
be better:

First, with Execute(), you never know whether the process actually was created.
For instance, suppose the program "module" was not found, or there was
insufficient memory, or some such thing.  You'd never know, and would go 
on with your own execution expecting it to be there.  You might find out later
when you tried to send it messages that it was not registered.

Second, how can you tell when the other process is ready to run?  You could 
wait for it to send you a message, but if it was never loaded, you'll hang
waiting for a messag ehtat will never come.  You could set up time-out
conditions, but that's a lot of work for what should be a simple operation.

(I must admit that I have not spent the time I should reading the PPIPC
and OOIPC discussion, so I don't know whether you have a solution for this
kind of problem built into the IPC protocols).

Finally, once the code is loaded, you have control of it before you call
CreateProc.  You can use the pointer to the laoded code to initialize
variables, call sections of code, etc., before starting the child process.
I use this technique in wIconify and vScreen to reduce the size of the
child process.  All the library opening, error checking, screen and window
lookups, and other one-time-only work is done in the loading program, not the
child program.  Of course, this means the child program can not be run on
its own as a separate command, too.

>                                            -- Pete --

Davide P. Cervone
dpvc@tut.cc.rochester.edu
dpvc@ur-tut.UUCP
DPVC@UORDBV.BITNET