Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!sun-barr!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Minix, Unix on the Amiga...
Message-ID: <122501@sun.Eng.Sun.COM>
Date: 18 Aug 89 19:00:22 GMT
References: <8908082312.AA10140@jade.berkeley.edu> <120408@sun.Eng.Sun.COM> <1243@quintus.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 24

In article <1243@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>Wouldn't it be more general to add to a task (process?) structure an
>address to call to clean up when the task exits?  It could be
>automatically called by Exit, if it is not 0, or when a task is removed.
>This would allow a program to track not only memory, but also locks,
>etc.  It would also allow a program to use whatever internal tracking it
>needs for its own purposes to clean up after itself.

This is a facility that ARP provides, I don't know if it is being considered
for 1.4 or not. It is much more useful and I've used it on several occassions
to do this kind of tracking. It helps when you want to kill a process that
is stuck in an infinite loop (although these days cpr "attach" works better
for me) but it is exactly as vulnerable as anything else if the program has
died because of a stray pointer or something. In some cases it is even more
vulnerable because it's tags are physically near the data that can get 
trounced. It would be interesting to see if a hack could be devised that
would protect these things with the 2620 MMU in the current address space
(MEMF_PROTECTED :-)) but that of course isn't a general solution.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"