Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!rochester!ur-tut!dpvc
From: dpvc@ur-tut.UUCP (Davide P. Cervone)
Newsgroups: comp.sys.amiga
Subject: Re: A proposed solution to the resource tracking problem
Message-ID: <81@ur-tut.UUCP>
Date: Tue, 15-Sep-87 12:40:46 EDT
Article-I.D.: ur-tut.81
Posted: Tue Sep 15 12:40:46 1987
Date-Received: Thu, 17-Sep-87 05:57:14 EDT
References: <636@sugar.UUCP>
Reply-To: dpvc@tut.cc.rochester.edu.UUCP (Davide P. Cervone)
Organization: Univ. of Rochester Computing Center
Lines: 50
Keywords: Resource tracking

[RoboCop wasn't thuroughly debugged yet...]

I have a concern that doesn't seem to have been addressed yet in the "kill
any process" suggestions.  While I beleive that there have been excellent 
methods proposed for making it possible to free up memory that's been 
allocated by a process, I'm not sure that that's all there is to it.  One 
must look at how that memory is being used.  For instance, if the memory
is part of a message that has been sent to another process, and that process
is still using that memory when you kill the original process, then you will
be freeing memory that is in use (not a good idea).  Does this mean that when
we kill a process, we should Wait() for all outstanding messages to be replied
to?  But what if the messages are never returned (like there is still a bug
in the program we're debugging)?  Do we not remove the process?  Or do we 
remove it anyway, and possibly risk a crash later?

How about other process that have pointers into the memory that I am using.
Suppose for instance, that I call OpenWindow() to get a new winodw.  That 
allocates memory.  It also links my window into the screen's window list,
creates a Layer structure and links that into the screen's LayerInfo structure.
If I deallocate that memory without properly closing the window, the screen's
window and LayerInfo lists will point to invalid data.  This could cause 
serious problems when I start to do aything with windows (like refresh them).

How about if a fopen() a CON: window?  That causes a new console task to be 
born (this takes up memory, but it belongs to another task).  If someone kills
my process without closing that CON: window, the console process will never
be removed, and will stick around in memory, doing I-don't-know-what.

Similarly, if I open the serial port, but don't close it properly (even if I
free the memory I used), no one else will be able to access the serial port.

While it is possible to encapsulate all the DOS and exec routines that 
allocate memory or other resources within new routines that track them, I am
not so sure it's a practical thing to add in after the fact.  There may just
be too many to change.  I hope I'm wrong, but it's not a project to be taken 
lightly.  And you need to realize that just freeing memory isn't enough
(and sometimes it's too much, like when that memory is in use by another
process).

In an environment where process share their resources in so many ways, I 
really worry about cleaning up after a process without some knowledge of what
that process was doing.  I hope someone finds a way to do it, though.

Sorry for the length of this, but I hope it helps some people think about
these issues.

Davide P. Cervone
dpvc@tut.cc.rochester.EDU
dpvc@ur-tut.UUCP
DPVC@UORDBV.BITNET