451061@UOTTAWA.BITNET (Valentin Pepelea) (08/09/89)
Randell Jesup <jesup@cbmvax.uucp> writes in Message-ID: <7570@cbmvax.UUCP> > Not to say some resource tracking wouldn't be a bad idea. However, > in a multitasking, lightweight process machine you have to be careful: many > programs pass off resources (permanently) to other processes (or to no one: > public structures, for example.) One can't merely add freeing of resources > on program exit to current programs; they'll break. How about a new flag for the memory allocation routines? If resource tracking is to be implemented, MEMF_NOTRACK would guarantee a memory block which would not be tracked, and therefore not be deallocated when the program exits. This would be a modifier flag like MEMF_CLEAR and MEMF_LARGEST, not a descriptor flag like MEMF_CHIP, MEMF_FAST, MEMF_PHYSICAL and MEMF_VIRTUAL. :-) Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
jesup@cbmvax.UUCP (Randell Jesup) (08/09/89)
In article <8908082312.AA10140@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Randell Jesup <jesup@cbmvax.uucp> writes in Message-ID: <7570@cbmvax.UUCP> >> Not to say some resource tracking wouldn't be a bad idea. However, >> in a multitasking, lightweight process machine you have to be careful: many >> programs pass off resources (permanently) to other processes (or to no one: >> public structures, for example.) One can't merely add freeing of resources >> on program exit to current programs; they'll break. > >How about a new flag for the memory allocation routines? If resource tracking >is to be implemented, MEMF_NOTRACK would guarantee a memory block which would >not be tracked, and therefore not be deallocated when the program exits. Not compatible: older programs don't use it. It's possible to a MEMF_TRACK, though. Whether we will or not is another question (that I'm not answering, sorry). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
shadow@pawl.rpi.edu (Deven T. Corzine) (08/09/89)
Randell Jesup <jesup@cbmvax.uucp> writes in Message-ID: <7570@cbmvax.UUCP> Jesup> Not to say some resource tracking wouldn't be a bad Jesup> idea. However, in a multitasking, lightweight process machine Jesup> you have to be careful: many programs pass off resources Jesup> (permanently) to other processes (or to no one: public Jesup> structures, for example.) One can't merely add freeing of Jesup> resources on program exit to current programs; they'll break. On 8 Aug 89 23:05:39 GMT, 451061@UOTTAWA.BITNET (Valentin Pepelea) said: Valentin> How about a new flag for the memory allocation routines? If Valentin> resource tracking is to be implemented, MEMF_NOTRACK would Valentin> guarantee a memory block which would not be tracked, and Valentin> therefore not be deallocated when the program exits. While this could work, it requires code changes, and if you're talking code changes anyhow [you really need to at some point] then I think a preferable solution is a mechanism to _pass_ [as in, explicitly] resources to other task(s)... where it would continue to be tracked. Certainly would work for memory -- being able to pass arbitrary resources would be nice. Comments? Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/10/89)
In article <8908082312.AA10140@jade.berkeley.edu> (Valentin Pepelea) writes: >How about a new flag for the memory allocation routines? If resource tracking >is to be implemented, MEMF_NOTRACK would guarantee a memory block which would >not be tracked, and therefore not be deallocated when the program exits. Isn't this the tail wagging the dog? Why can't we just build a *real* set of memory allocation routines on top of the Exec routines like the original developers intended? Have the equivalent of malloc and free or some other set of routines that track the memory for you. Currently, C users can just use these two to allocate and deallocate memory, and when the program exits they all get freed. Things like device nodes which are cons'd up and given away should have constructor/destructor functions that are separate from the memory allocation routines. About the only OS support I can think of would be to put the memory on some "well known" list (like tc_MemEntry) so that all of the compiler writers would know where to stick their memory allocations to be freed. Of course we need some way of selecting "types" of memory which the C library routines don't provide. But this is more of an interface problem than anything else. AllocMem() has all of the constructs it needs to be a good underlying allocator, now lets build a nice set of user friendly routines on top of it. --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!"
pds@quintus.UUCP (Peter Schachte) (08/17/89)
In article <120408@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: [about memory tracking...] >About the only OS support I can think of >would be to put the memory on some "well known" list (like tc_MemEntry) >so that all of the compiler writers would know where to stick their >memory allocations to be freed. 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. It might be helpful if the task structure also had a longword allocated to the program to store data for this purpose. Then the standard malloc & friends could chain allocated memory from this pointer and store a simple chain-from-this-location-Freeing-everything function in the task's cleanup-function slot. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/19/89)
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!"