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