Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!ubvax!ardent!rap!rap
From: rap@rap.ardent.com (Rob Peck)
Newsgroups: comp.sys.amiga.tech
Subject: Re: File Requesters
Message-ID: <6413@ardent.UUCP>
Date: 11 May 89 22:34:27 GMT
References: <6374@ardent.UUCP> <8077@killer.Dallas.TX.US>
Sender: news@ardent.UUCP
Reply-To: rap@rap.ardent.com (Rob Peck)
Distribution: na
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 40

In article <8077@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes:
>in article <6374@ardent.UUCP>, rap@rap.ardent.com (Rob Peck) says:
>[lots of stuff about file requesters... then:]
>
>> clear enough in the original posting.   And if one makes the file
>> requester code a part of a sharable (reentrant) library, the function
>> "malloc" could be used to allocate these buffers in the first place
>
>Uh, Rob, slight problem here. "malloc" works somewhat like the
>Intuition function "AllocRemember", i.e., it calls AllocMem and then
>adds an entry into its memory list. The pointer to its memory list is
>in the program's static memory, and the address of that pointer is
>hard-wired into "malloc" and "exit" at link time. A shared library's
>copy of "malloc" will thus have a different RememberList than the
>program's copy of "malloc"... meaning that when the program's copy of

OK, thanks for the feedback.  I guess the best thing to suggest, (based
on my original posting then, with the data structure, would be to add to
that structure an AllocRemember base pointer and INSIST that the user
call the file requester one last time to clean up for every file
directory that be cached.  Sounds reasonable.

To all who replied, directly or via the net, thanks for the info about
the actual implementation of malloc.  If the Amiga ROM had malloc built in
and could tell which task did each allocation (bigger memlists, eh?)
then as a task exited, the UnloadSeg or something could walk the internal
malloc lists looking to free everything associated with a particular task.
But with the malloc code in its current state, as described above, and
linked into the file-requester code, it would not be reentrant and would
indeed cause problems.  

Hmm, maybe if we make it a full process instead of a shared library,
and then REZ it (instead of RESIDENT), we have yet another way to solve
the single global pointer malloc problem...  REZ is (Jim Goodnow's 
equivalent of RESIDENT, but done differently.  Each incarnation of 
the program would get its own private data segment, thereby providing 
a local copy of what woulda been a global pointer.  Yet another way 
to go perhaps.

Rob Peck