Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!gatech!udel!mmdf
From: iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley)
Newsgroups: comp.sys.amiga
Subject: Re: resource reclamation
Message-ID: <3763@louie.udel.EDU>
Date: 18 Aug 88 19:01:41 GMT
Sender: mmdf@udel.EDU
Lines: 122

[In "Re: resource reclamation", Chuck McManis said:]
>
> In article  (Miles Bader) writes:
> > How come simple resource reclamation isn't done?  It seems like it
> > would be pretty simple to hang a list of allocated resources off a
> > task...
>
> Because it isn't. The original DOS specified for the Amiga included
> resource reclamation, however when time got tight and Commodore had
> to go with MetaCompCo's modified version of TriPOS, there wasn't time
> to put it in. If you look at some of the structures you will notice
> that there entries for Tasks such as tc_MemEntry which were for this
> kind of stuff.
>

It still is.

> That is not to say that it isn't possible. The ARP project (AmigaDOS
> Replacement Project) has created a library which allows you to track
> resources and free them on exit.
>
> uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
>

Let's discuss how memory tracking is presently handled.  There are
three categories to consider: Task, Process, and CLI command.

1) Task

You create a task by calling

AddTask(task, initialPC, finalPC),

which adds a given task to the TaskReady list.  Here "task" is an existing
Task structure, "initialPC" is the entry point, and "finalPC" is an optional
cleanup routine.

The final code is pushed on the stack as if it were the outermost return
address.  If finalPC is 0, the system default cleanup is used instead,
which merely calls RemTask().  RemTask() removes the task from the Ready
list and deallocates the MemEntry list.  Deallocation of the Task structure
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
itself is left to the parent who created it.


2) Process

There are two ways of creating processes.  The external AmigaDOS function

CreateProc(*name, pri, seg, stkszb)

and the internal (undocumented) function

createproc(segarray, stkszlw, ^name, ^gv)

The internal function differs in that:
        The process name is a BSTR.
        The stack size is in long words.
        The code is passed as an entire SegArray, not just one SegList.
Both NEWCLI and RUN call this function.

The external function allocates memory for the Process structure and the
stack, and puts this as a single entry on the MemList.  It AllocMem's
space for the SegArray, but does not put this on the MemList.  The 1st
and 2nd SegLists in the SegArray are copied from the parent, the 3rd is
the one supplied by the caller.  It then calls AddTask() with special
initialPC and finalPC.  The finalPC code frees the SegArray.

3) CLI command

A CLI command is not a separate task or process.  It reuses the Task
Process and CLI structures of the CLI.  It is called from the CLI as
a subroutine but uses its own stack.  (This effectively makes it a
coroutine, but it does not use the BCPL coroutine mechanism.)
The CLI handles all the allocation and deallocation internally.
This includes:

LoadSeg'ing and UnLoadSeg'ing the code.
Allocating and deallocating the requested stack.
Locking and UnLocking the Current Directory.



Anyway, the moral is that the AmigaOS is quite diverse.  Memory resources
cannot be tracked from Exec at present because much goes on that Exec
does not know about.  The MemEntry will be deallocated automatically
whenever a Task ends, but when this will happen depends on whether you are
running from the CLI or from the Workbench.

The Workbench creates a new process each time it launches a program, but
the CLI does not.  If the CLI is used, a Task will end only when ENDCLI
is executed or when a background (RUN) CLI commits suicide.
(Unless of course the program spawns Tasks of its own.)



True resource tracking is even more complicated.  In addition to memory
you could keep track of open file handles, and close them automatically
when you terminate.  This is done in ARP.  Of course this kind of tracking
is also done for you when you use the Unix-compatible malloc() and fopen()
functions.

But on the Amiga there are many more resources to worry about.  An aborted
process may have opened MessagePorts, IORequests, Windows, Screens, etc.
Each of these requires a different specific cleanup action, not just
freeing of memory.  The actions may even have to be taken in a definite
order.

Conceivably you could keep track of all these things and write a general
cleanup routine.  Then someone will add his own library and expect the
system to cleanup those resources too.


--

Bill Kinnersley
  Physics Department            BITNET: iphwk@mtsunix1
  Montana State University      INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu
  Bozeman, MT 59717             CSNET: iphwk%mtsunix1.bitnet@relay.cs.net
  (406)994-3614                 UUCP: ...ucbvax!mtsunix1.bitnet!iphwk
"This message was packed as full as practicable by modern electronic
equipment.  Some settling of contents may have occurred during transmission."