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