Conference hydra::amiga_v1

>    before begining the main work.  Our division laid the idea of the
>    Amiga's multitasking in my lap.  So I came to you!  The loyal DEC

Do you mean DEC has you working on Amiga?

John    

    Better yet, is DEC doing adventure games?

    - Z

    sorry...
    
    You misunderstood my problem.  I used the word "division" as in
    to divide between myself and my friend what we are trying to get
    straight.  This is non-DEC related.  I'm just working on this in
    my spare time.  I just thought to ask here because you might know
    a book/source/etc. that explains concisely how to tap the Amiga's
    multitasking resources.  I didn't mean it to sound like this was
    something for work or even done at DEC.  Once again, sorry...I guess
    I shouldn't have asked here but I found very little code utilizing
    the tasking features and the books I have at home only has a very
    small, cryptic section on multitasking.  
    
    Sorry again, George
    

Re: .0

Amiga programmers can use several different methods of using multitasking
in their programs.  It depends on what you need to do.

For example, if you have a program that just wants another process to do
something for it in parallel, you could just call the Execute function
with a command sting like "RUN FOO".

If you have in mind a program where several different tasks are all
doing their jobs and providing information back to some central
process, you might want the processes to just send messages to each
other.

If you want processes to be very tightly bound together and to update
common data structures in memory, you will have to provide your own
spinlocks to coordinate access.  (Actually, the system does provide
semaphores, but I never have been interested enough to learn how to
use them.  They aren't documented in the manuals; you need to order
the Developer's Update for documentation.  Ordering the developer's
update is a good idea anyway.  It only costs $25 and anyone can order
it.

So, what what are you trying to do?

Re .3:

	This is the (at least one) correct place to ask about AMIGA
	stuff.  Your questions will probably help someone else
	sometime...

John

    Right now its more of an educational thing.  The actual application
    isn't cut and dried but in essence (among other things) I want to
    have multiple large programs and I didn't know if there was a clean
    way to have them cut to one another.  Example: Program A is huge
    and it's last line EXECUTEs Program B, now both B and A are resident.
    I want it to EXECUTE Program B and terminate A.  In hindsight I
    guess I could have it call Program C using RUN and Program C can
    wait until memory is freed from A and then EXECUTE B, but I thought
    there might be a cleaner way and was unsure what resources might
    exist to set up the equivalent of mailboxes between processes.
    
    I'll just have to do some experimenting and poking through sources
    and see what I can see....
    
    George
    

	Aztec C has the FEXEC functions, which will do exactly what you
	need. Program A will FEXEC Program B with a command line passed
	as argument, and upon completion Program B will return to caller.
	I have not been able to find out how return even a status from B
	to A yet but there's got to be a way. On the other hand, you can
	use EXEC functions which work the same but don't return to the
	caller. FEXEC by the way is not described in my Aztec C manual.
	I suppose they both make use of less specific system routines
	but I havent received the ROK Kernal manuals yet so I can't tell
	which.
Iv.

    Aztec C also provides a way to do overlaying within a single
    task, so you don't need to use multiple tasks unless you want
    simultaneous threads of execution for some purpose.

    -jim

Re: .7

>	I have not been able to find out how return even a status from B
>	to A yet but there's got to be a way.

As it turns out, for a program that is run asynchronously to return a
exit code is a hard problem because of the design of AmigaDOS.  In fact,
it is no easy task to do even for synchronous programs.  This is a
flaw in the design of AmigaDOS.

>>	I have not been able to find out how return even a status from B
>	to A yet but there's got to be a way.
>
>As it turns out, for a program that is run asynchronously to return a
>exit code is a hard problem because of the design of AmigaDOS.  In fact,
>it is no easy task to do even for synchronous programs.  This is a
>flaw in the design of AmigaDOS.
>


Couldn't the "parent" program allocate a small chunk of PUBLIC memory
(ala global section), then pass it's address (no VM to worry about here!)
in a message to it's child. Then the child could write it's completion
status in that area.

John

Re: .10

Yep, it is always possible for two programs to make some sort of agreement
about returning status codes.  However, consider the case of two arbitrary
programs.  There already exists a protocol for passing back return codes
for CLI programs.  Most programs manage to do this.  However, this
information is unavailable when the program runs as a separate process
(CLI's run programs in the CLI's process context).  That is the design
flaw I mentioned.