Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!nbires!hao!husc6!think!ames!ptsfa!hoptoad!academ!uhnix1!sugar!peter From: peter@sugar.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: A proposed solution to the resource tracking problem (long) Message-ID: <695@sugar.UUCP> Date: Fri, 11-Sep-87 19:24:34 EDT Article-I.D.: sugar.695 Posted: Fri Sep 11 19:24:34 1987 Date-Received: Sun, 13-Sep-87 19:50:55 EDT References: <8709082136.AA19121@cory.Berkeley.EDU> Organization: Sugar Land UNIX - Houston, TX Lines: 68 In article <8709082136.AA19121@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > 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? Put up with doubling the memory requirements of the task, or else allocate a bigger chunk to each task (say: 128 bytes minimum), and give it bits of this chunk as it requires. Make AllocMem act more like Malloc. The free list within the 128 byte chunk can be manipulated as normal. Messages are tougher. If SendMsg transfers the ownership of the segment containing the message, or better yet marks it as having shared ownership, that should help most cases... shared chunks can't be freed automatically. It's still not perfect, but the only place this will cause problems is if you kill the task. All messages should be back at the originator by the time the task exits normally. Killing a task is an emergency measure anyway. > 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. I don't think they should do this. The only resource a program should expect to hang around is a process it has LoadSegment()ed and CreateProcess()ed. And which has its own resources. Cna you name any programs that expect anything else to hang around after they go away? The only one I can think of is something that chews up RAM so your 512K-only programs can run. Oh yes, the Manx SET command, but that's a little joker that can easily be rewritten to give up its memory nicely. > 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!!!! This is a real problem. But since we're modifying the libraries anyway and not using RemTask to Kill tasks, it's no real bigee. > 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. I don't see why. One mark of a good program is that when you exit the Free Memory list in the workbench title bar hasn't changed. Most software should in fact work well with resource tracking. > 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. We would also be able to kill old programs that were well-behaved. Also, this will have to be done eventually to allow for protected mode operation. Why not start now. Look how well burying heads in the sand has worked for IBM and Microsoft. If the Amiga doesn't go to protected mode it will be dead within 5 years. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter -- 'U` <-- Public domain wolf.