Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Launching new Tasks in C
Message-ID: <11919@agate.BERKELEY.EDU>
Date: 11 Jul 88 11:12:06 GMT
References:  <11752@agate.BERKELEY.EDU> <2261@ur-tut.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 42

In article <2261@ur-tut.UUCP> dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone) writes:
>
>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.

True, but this is the sort of thing that IPC has to handle as a matter of
course.  The sender has to expect that an attempt to send a message may
fail; it'll be informed of this and will have to take whatever action it thinks
necessary.
(Actually Execute() DOES return a success code, though I have to confess
I'm not sure what'd happen if the RUN command failed -- whether it would
fail the execute too, or not.)

>
>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.

Same thing, basically.  You shouldn't actually care whether a process is
running until you want to send it something; you can always 'ping' it if
you need to know sooner.

>
>Finally, once the code is loaded, you have control of it before you call
>CreateProc.  [........]

I hope people won't write modules to run under IPC this way.  My feeling
is that they should be self contained, to be started up like any other program,
without special conditions or considerations.  If you want a module to
change its run-time state -- send it a message to do so.  Closely linked
processes and tasks like you're suggesting are fine for lots of things,
but the idea of IPC I think is to decouple things so that we can mix and
match modules more easily.

					-- Pete --