🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #13486

Re: resource tracking

#13486
From: Chuck McManis
Date: Sat, 03 Feb 1990 19:59
46 lines
2790 bytes
Warning: If you do not enjoy watching the physical abuse of dead horses, 
stop reading this message.
 
In article <355.25C92297@weyr.FIDONET.ORG> (Jeff Petkau) writes:
>It [resource tracking] _is_ trivial.  For memory, simply keep a pointer ...

Jeff goes on to explain something that looks a bit like the ARP resource
tracking code. 

The ARP code does this fairly well and actually takes it a step further
in that you can have "deallocator" functions that will deallocate the
specific resource etc etc. 

BUT, and this is the killer, WHY do people want resource tracking? 
There are two reasons, the second is so that a program can just call
exit() and have anything that it had allocated freed. That is the easy
one. The first and foremost reason that people want resource tracking
for is so that they can somehow kill an errant process and have it
automatically free up it's resources. By definition, IT IS NOT POSSIBLE
TO GUARANTEE THAT THIS WILL WORK. 

Why? Because you cannot know in a non-MMU based system just what the
heck the "errant" process stomped on. You can "play the odds" which
is what GOMF does and GUESS that the process didn't do any unknown
damage to the system lists, but you cannot GUARANTEE it. The difference
is the same between a hack and a product. It is _non trivial_ to 
make this possible in the Amiga system. Something I personally would
like to see would be a "runprotected" command that would start a
program and setfunction the appropriate vectors so that the program
would run with the MMU protecting all addresses outside of it's 
range. (determined at LoadSeg time and after each call to AllocMem)
It need only protect them from Write Access and could stop the 
program when it did something stupid. Too bad Valentin already has
his degree this might be a good thesis project :-) 

This would be a great debugging tool and allow a developer to 
release it with confidence on the unsuspecting user community
*knowing* that it doesn't do weirdo writes outside of its address
space.



--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"
Technical Details
Message-ID: <131188@sun.Eng.Sun.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!stpeter!cmcmanis
References: <355.25C92297@weyr.FIDONET.ORG>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!stpeter!cmcmanis
From: cmcmanis@stpeter.Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: resource tracking
Message-ID: <131188@sun.Eng.Sun.COM>
Date: 3 Feb 90 19:59:11 GMT
References: <355.25C92297@weyr.FIDONET.ORG>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 46