Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!sdcsvax!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: A proposed solution to the resource tracking problem (long)
Message-ID: <8709082136.AA19121@cory.Berkeley.EDU>
Date: Tue, 8-Sep-87 17:36:06 EDT
Article-I.D.: cory.8709082136.AA19121
Posted: Tue Sep  8 17:36:06 1987
Date-Received: Wed, 9-Sep-87 07:26:35 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 63


	Interesting proposal. 

	Let's put aside the memory allocation tracking for the moment and
first concentrate on other resources.  All other system resources are 
either device or library oriented, or special EXEC calls.  For instance,
to use DOS file handles you must open the DOS library; to use the 
SERIAL.DEVICE, you must open the serial device.  To use Intutition you must 
open the intuition library.  To allocate resources you must make the proper 
EXEC calls.

	Assuming the libraries and devices did their own tracking of which
OpenLibrary/OpenDevice is associated with an IO request, all EXEC would have
to do is keep a list of all currently open libraries and devices for a
specific task.  Even if a task forgets to close a library, EXEC would have
the list and would close the library for the task (the library/device then
closing associated IOrequests, windows, etc...). This takes care of Libraries 
and Devices.

	Other items EXEC would have to track would be those EXEC calls which
transform the machine in some way... things intuitively obvious like 
SetIntVector().

	The above is relatively simple and incurs almost no overhead in terms
of memory and time, though it will mean an extensive rewrite of the OS.  BUT 
now we come to memory.  The problem with tracking memory is that in most cases
programs allocate small chunks at a time and to stick a linked list (or some
other structure) tag onto each chunk can, in the worst case, double the 
memory requirements of a task.  Other problems occur when we are bandying
messages back and forth between tasks... we must allow for multiple owners
of a memory segment.  Anybody have any bright ideas?

COMPATIBILITY:
	It is impossible to make resource tracking compatible with current
software.  That is, you *can* resource track current software, but cannot
free those resources when the task is killed even though you know what they
are.  REASON:  Simply put, many programs rely on resources they haven't 
closed (memory, interrupts) NOT to be released when they exit.  Another
reason of equal import is the fact that under the current OS, you can
RemTask() a task which is in the middle of a library call.  Clearly, the
libraries were not set up to handle something like that happenning!!!!

	Clearly we must add EXEC calls to allow resources to be kept resident
on exit.  Current software does not know about these calls so the ABSOLUTE BEST
we can hope for is to make a standard for NEW software that is written.

CONCLUSION:
	The end result would be that we would then be able to kill new
programs which understand the new EXEC calls and still not be able to kill
old programs which do not.  New programs would make an EXEC call 
TrackResources() at the very beginning to turn on resource tracking and 
automatic deallocation, etc....  Since old programs do not make this call,
EXEC knows they are old and will not attempt to track them.  Under the 
new order, programs would be able to selectively turn on and off tracking 
for certain operations.  Under the new system, Libraries and Devices would
be constrained to set a flag (or something) ensuring they are not killed
in the middle of execution when called from a task.  If any task opens a
library without this capability, resource tracking would automatically be
turned off and kills would not be allowed on that task (Basically, you would
not be able to kill any task which did not have resource tracking turned on).


					-Matt