🚀 go-pugleaf

In article <13592@cup.portal.com> (Dana B Bourgeois) writes:
>Does anyone use the AllocRemember() and FreeRemember() calls documented in the
>Addison-Wesley 'Intuition Reference Manual', pp 211-214?  If not, why not?

I use them, when they are useful. They have two big drawbacks which are
sort of related. One you can't "mark" the list and then free back to
the last mark. This is useful when half way through a routine your
request for memory fails and you would like to unwind and recover. 
The second is you can't "join" lists. So if you use a separate variable
during a subroutine (faking a mark) then when you are ready to return
you can't say JoinRemember(ptr1, ptr2); to put everything on one list.

>The reason I ask is that I have seen comments on UseNet and in magazine 
>articles that say AmigaDOS does not have any resource tracking and that lack
>is a big problem.  Perhaps those calls don't work or perhaps they don't solve
>the problem that needs to be solved.  I'd like to know.

They don't solve the problem. When you force a task to exit via an external
force in say TOPS-20, all of the resources it has allocated are freed 
automatically. On the Amiga those are not freed and are "lost" until the
next reboot. There is a big religious debate about why you can or cannot
do this (it has to do with what do you trust when a program on an unprotected
memory machine goes south?) and generally I don't believe we'll see it until
the OS can be sure that no one has stomped on it's lists. 

On a side note, there has been much talk about what to use the MMU on the
A2620 for. Personally, I'd like to see a version of ADOS that kept all
of it's lists (like memory, tasks, etc) under lock and key. Only making
memory "writable" when it is allocated via AllocMem() or some such. That
way you would turn a lot of GURU crashes that corrupt location 4 or 
the free memory list, into simple task held's because the task tried
to write outside it's legal memory space. Then a new reboot ("hot reboot")
that would just clear out the user tasks and such and put you back into
the "boot" state nearly instantly. In either event, I want to see a version
of CARD: that uses the MMU to protect itself. No more worries about losing
it due to an errant task.

--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.