hamish@waikato.ac.nz (08/06/90)
Ok folks, how about another go at getting a little bit of hardware protection
for the amiga, and a bit of resource tracking.
So far objections are because of
1 resource tracking will make things slower.
Well ARP doesn't seem to be suffering too much does it? And that
has had resource tracking since day one. IMNSHO it would be a better
OS if an errant program could be cleaned up after it was killed off.
2 People don't use MEMF_PUBLIC for messages.
Well if we make all unallocated memory to be non-readable and
non-writable that would probably catch a few errant pointers. The
code hunks could be make read-only for all tasks and if people are
using a code hunk to hide a message port (ie for data) then they
deserve to have their program curl up and die on them.
data hunks and allocated data could be rw for the owner and ro for
everybody else. After all how many programs actually change a message
once it is read?
The fact that we must pass a pointer either means that the library
routines for sending a message must be able to write to the message
port being sent to, or the message port must be rw. I favour the
library routine to be able to get rw access as this would cover
a lot of errant programs stamping on people message ports.
Write protecting the data pages is probably the only change that
would make the system a little slower at swapping tasks, but it
would make a really stable computer.
3 Write protecting ram based libraries and bottom of memory.
Well I don't remember any good reason for not write protecting
these. From what I gather the enforcer option does the second,
but what about the first. After all who needs to write to libraries
apart from routines (supposedly through the OS) that patch them.
OK. I've thrown the cat amongst the pigeons. Can anybody now convince me, and
themselves that it won't work. How hard can it be to change LoadSeg() and
UnLoadSeg() to make code hunks ro?
--
==============================================================================
| Hamish Marson | Internet hamish@waikato.ac.nz |
| Computer Support Person | Phone (071)562889 xt 8181 |
| Computer Science Department | Amiga 3000 for ME! |
| University of Waikato | |
==============================================================================
|Disclaimer: Anything said in this message is the personal opinion of the |
| finger hitting the keyboard & doesn't represent my employers |
| opinion in any way. (ie we probably don't agree) |
==============================================================================valentin@cbmvax.commodore.com (Valentin Pepelea) (08/08/90)
In article <1145.26bd4989@waikato.ac.nz> hamish@waikato.ac.nz writes: > > 1 resource tracking will make things slower. > Well ARP doesn't seem to be suffering too much does it? And that > has had resource tracking since day one. IMNSHO it would be a better > OS if an errant program could be cleaned up after it was killed off. The problem is not that resource tracking has not been implemented, but rather that resource tracking has not been promoted as a concept. Therefore we have software today that would barf all over resource tracking enhancements. For example, how about a program that allocates some memory for a message, sends the message to another task and then quits. The other task then receives the message and frees its memory when it is done with it. Now if we implement resource tracking which frees all the memory of a program when the program exits, then the memory of the message will be freed also. When the second task then tries to access that message... Poof! The same problem arises with opened windows, message ports, etc... > 2 People don't use MEMF_PUBLIC for messages. > Well if we make all unallocated memory to be non-readable and > non-writable that would probably catch a few errant pointers. Well, some has already suggest that we write a trap handler which reports on the serial port at 9600 illegal accesses to free memroy. Consider it done. :-) Oh, and you're right. It does catch a large number of errant tasks. I call this trap handler my Guardian-Angel; I don't leave the computer without it. :-) > The code hunks could be make read-only for all tasks and if people are > using a code hunk to hide a message port (ie for data) then they > deserve to have their program curl up and die on them. Unfortunately this is too common. Much to common. I don't know of anybody that does not do this. (they have not advertized) I do this all the time. > 3 Write protecting ram based libraries and bottom of memory. > Well I don't remember any good reason for not write protecting > these. Both the ROM and bottom of memory (page zero) are write protected. Actually page zero is also read protected. A special check is made to verify whether location 4 (pointer to address of ExecBase) is being read. > After all who needs to write to libraries apart from routines > (supposedly through the OS) that patch them. If it is a disk-based library, then chances are it will have R/W data embedded in code hunks. Sorry. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
hclausen@adspdk.CBMNET (Henrik Clausen) (08/09/90)
>In article <13693@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes: >The problem is not that resource tracking has not been implemented, but rather >that resource tracking has not been promoted as a concept. Therefore we have >software today that would barf all over resource tracking enhancements. Yes - if we _force_ resource protection/tracking upon them. [ Well known and correct example of problems herein deleted. ] Now, if a few hooks where in there to allow applications to explicitly ask for protected,virtual and non-shareable memory, (AllocVMem() ?) they could benefit on the larger machines, while still running on non-MMU machines. The programmers of large, ram-intensive applications would embrace this. They would still use AllocMem() for message ports and whatever else is going to be shared with other tasks. For non-MMU machines, these calls would behave just like AllocMem(), apart from the resource tracking. Would this break anyone? Valentin? >>Both the ROM and bottom of memory (page zero) are write protected. Actually >page zero is also read protected. That's real nice. The OS doing so, or some devilish debugging tool? Have a nice day -Henrik -- | Henrik Clausen, Graffiti Data (Fido: 2:230/22.33) | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Do not accept the heart that is the slave to reason" - Qawwali trad__/
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/11/90)
In article <hclausen.2309@adspdk.CBMNET> hclausen@adspdk.CBMNET (Henrik Clausen) writes: > > Now, if a few hooks where in there to allow applications to explicitly ask >for protected,virtual and non-shareable memory, (AllocVMem() ?) they could >benefit on the larger machines, while still running on non-MMU machines. > ... > They would still use AllocMem() for message ports and whatever else is >going to be shared with other tasks. > ... > For non-MMU machines, these calls would behave just like AllocMem(), >apart from the resource tracking. > ... > Would this break anyone? Valentin? Providing new functions with added functionality cannot break any existing programs. But embarking on such a venture requires energy, intitiative and presence of clear mind which not everybody has. Another problem is that even if you provide the possiblity for new applications to run protected within the environment, the fact that older programs cann still jog around the address space and wreak havoc, defeats the initial purpose. Either you provide memory protection to everybody simultaneoulsy, or you don't at all. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
lshaw@walt.cc.utexas.edu (logan shaw) (08/12/90)
In article <13756@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Providing new functions with added functionality cannot break any existing >programs. But embarking on such a venture requires energy, intitiative and >presence of clear mind which not everybody has. > >Another problem is that even if you provide the possiblity for new applications >to run protected within the environment, the fact that older programs cann still >jog around the address space and wreak havoc, defeats the initial purpose. But they can't wreak havoc with the memory declared as protected. Granted, it won't be 100% safe, but it will sure be alot better than it is right now. >Either you provide memory protection to everybody simultaneoulsy, or you >don't at all. I was under the impression that (motorola, at least) MMU's worked by setting certain memory pages with certain attributes (protected, etc), so the programs which asked for protected memory would be protected from everything, but older programs wouldn't be protected from newer programs. At any rate, all the newer programs (at least all the well written ones) would be asking for protected memory, so it eventually would be everywhere. Anyway, I don't see a disparity here, because I'm pretty sure that even in systems like UN*X, you can still request unprotected memory if you want it. So what's the problem? Isn't there enough space for things like this in a 512K rom? It can't be _that_ difficult to write. PLEASE can we have this in 2.1? Please, please, please? Pretty please with syntactic sugar on top of it? Just _once_ i'd like to see a requestor like this: /---------------------------------------\ | CLI Process 2 tried to hose Process 3 | | | | /--------\ /--------\ /-------\ | | | Freeze | | Ignore | | Reset | | | \--------/ \--------/ \-------/ | \---------------------------------------/ >Valentin >-- >The Goddess of democracy? "The tyrants Name: Valentin Pepelea >may distroy a statue, but they cannot Phone: (215) 431-9327 >kill a god." UseNet: cbmvax!valentin@uunet.uu.net > - Ancient Chinese Proverb Claimer: I not Commodore spokesman be ============================================================================ "The beauty queen, clevely clad, Logan Shaw admires herself in a cigarette ad. lshaw@ccwf.cc.utexas.edu Will she admit that all was in vain ======================== when the face in her mirror cracks like a windowpane?" -Elim Hall, _Things_Break_
caw@miroc.Chi.IL.US (Christopher A. Wichura) (08/12/90)
In article <13756@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes: >Another problem is that even if you provide the possiblity for new applications >to run protected within the environment, the fact that older programs cann still >jog around the address space and wreak havoc, defeats the initial purpose. >Either you provide memory protection to everybody simultaneoulsy, or you >don't at all. This I don't understand. If an old program goes and stomps on memory protected by a program using some new OS call, shouldn't an exception be generated which the rexception handler would pick up? Thus you get a software failure requester and no `real' harm is done. Given that if the memory wasn't protected you could easily end up with the stomped on program getting very confused and crashing the system, I would rather have the software failure requester... -=> CAW /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Christopher A. Wichura caw@miroc.chi.il.us (my amiga) u12401@uicvm.uic.edu (my school account) Please! Do not send mail to my school account unless mail to miroc bounces. I often do not check uicvm.uic.edu for periods in excess of a week. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////////
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/14/90)
In article <35789@ut-emx.UUCP> lshaw@walt.cc.utexas.edu (logan shaw) writes: > >> Another problem is that even if you provide the possiblity for new >> applications to run protected within the environment, the fact that older >> programs can still jog around the address space and wreak havoc, defeats >> the initial purpose. > > But they can't wreak havoc with the memory declared as protected. Granted, > it won't be 100% safe, but it will sure be alot better than it is right now. > > I was under the impression that (motorola, at least) MMU's worked by setting > certain memory pages with certain attributes (protected, etc), so the > programs which asked for protected memory would be protected from everything, > but older programs wouldn't be protected from newer programs. Not quite. Protected tasks would still have their TCB in MEMF_PUBLIC memory, which by definition means "Go ahead, stomp on me!" Ditto for memory lists message ports, messages, I/O requests, etc. If you cannot provide 100% memory protection and recoverability, then you might as well not provide it at all. You might disagree, but remember, I'm always right. ;-) > It can't be _that_ difficult to write. PLEASE can we have this in 2.1? > Please, please, please? Pretty please with syntactic sugar on top of it? As I have said before, the technical difficulties are not what is keeping us from coming out with incredibly useful enhancements. You have to factor in the energy constant, the resistance ratio and the friction coefficient. I found out the hard way. > Just _once_ i'd like to see a requestor like this: > /---------------------------------------\ > | CLI Process 2 tried to hose Process 3 | > | | > | /--------\ /--------\ /-------\ | > | | Freeze | | Ignore | | Reset | | > | \--------/ \--------/ \-------/ | > \---------------------------------------/ Indeed, coming out with a fully memory protected operating system which protects even old software, but remains compatible by presenting one of these requesters every time an illegal access happens, is technically possible. But these requesters would pop up several times per second, and would leave novice users rather confused. Another option would be to come up with an operating system that provides full memory protection, but would allow the user to turn it on only optionally. Easy. But to evaluate the likelyhood of such a thing happening, you have to factory in the energy constant, the resistance ratio and the friction coefficient... Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
brian@babbage.csus.edu (Brian Witt) (08/16/90)
In article <13785@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <35789@ut-emx.UUCP> lshaw@walt.cc.utexas.edu (logan shaw) writes: >> >>> Another problem is that even if you provide the possiblity for new >>> applications to run protected within the environment, the fact that older >>> programs can still jog around the address space and wreak havoc, defeats >>> the initial purpose. > If you cannot provide 100% memory >protection and recoverability, then you might as well not provide it at all. > >You might disagree, but remember, I'm always right. ;-) >Indeed, coming out with a fully memory protected operating system which >protects even old software, but remains compatible by presenting one of these >requesters every time an illegal access happens, is technically possible. >But these requesters would pop up several times per second, and would leave >novice users rather confused. > >Another option would be to come up with an operating system that provides ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >full memory protection, but would allow the user to turn it on only optionally. >Easy. But to evaluate the likelyhood of such a thing happening, you have to >factory in the energy constant, the resistance ratio and the friction >coefficient... Uh, excuse me, but this is sounding like the reasoning behind Microsoft's OS/2 after they looked at MS-DOS.... Things weren't right for protected mode, window servers, and programs that required more than 640K memory. (DOS and COMMAND.COM and such were taking over 90K themselves!) What would a "protected mode OS" on the Amiga smell like? Would a protected mode OS be viable for the Amiga market? *** What is the Amiga Market *** If you say the Amiga should compete in Markets similar to the PS/2 world, then I say: If there isn't an "AmigaDOS"-type OS that has protected mode before Christmas 1991, I'm out of here. :-( :-( :-( I bought the machine for Multi-tasking, and have enjoyed its power and flexibility. However, the graphics and exec had stood frozen almost since I bought the machine (dec 1985). I'm very jealous of my friends with '386 clones showing me VGA graphics. _The Concepts_ inside of OS/2 and Presentation Manager are "one-up" on the Amiga. My personal opinion is kill it [OS/2] or lose it. Although the NeXT cubes aren't really selling, their software will be showing up on machines labeled I.B.M. (Maybe my depression has been brought on by SIGGRAPH -- all those pretty displays; 1020 x 800 x _so_ many colors.) This is starting to get long... I'd like to see a capability based O.S. similar to Amoeba (Andy Tannenbaum, et al). Maybe running NeWS.. 14" to 25" displays, price starting about $5000. But that's not an Amiga anymore.. :-( > >Valentin >-- >The Goddess of democracy? "The tyrants Name: Valentin Pepelea > - Ancient Chinese Proverb Claimer: I not Commodore spokesman be --- President Hussein of Iraq isn't evil, he just wants America to carpool! --- brian witt, brian@babbage.ecs.csus.edu
C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) (08/17/90)
On 10 Aug 90 19:56:24 GMT Valentin Pepelea said: >Another problem is that even if you provide the possiblity for new applications >to run protected within the environment, the fact that older programs cann >still >jog around the address space and wreak havoc, defeats the initial purpose. >Either you provide memory protection to everybody simultaneoulsy, or you >don't at all. Obviously we can't provide memory protection to everybody simultaneously. For the forseable future there will always be old programs that will not work properly with memory protection and people that want to run them. However, memory protection is too valuable to just write off. As has been mentioned before (I beleive) The operating system and unprotected programs could be lumped together. Protected programs would, of course, be isolated from each other and the OS. Now, what happens when an unprotected program tries to step on a protected. program? I'd call that a task held. It's not very nice but at least it stops the errant program from doing real damage. Is this as good as "real" memory protection? No. But it's better than we have now and starts the process going toward "real" memory protection. In the beginning it wouldn't be much differnt than now becuase protected programs be few. But if the memory in protected programs is larger than the OS then errant programs will usually be stopped by protection violations. This *would* be more stable. And as time progressed it would only get better. Eric Edwards: c506634 @ "The 3090. Proof that by applying state of the Inet: umcvmb.missouri.edu art technology to an obsolete architecture, Bitnet: umcvmb.bitnet one can achieve mediocre performance."
mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) (08/17/90)
Now, what happens when an unprotected program tries to step on a protected. program? I'd call that a task held. It's not very nice but at least it stops the errant program from doing real damage. No, it stops the errant program from doing any _more_ real damage. You don't know what it's managed to trash before it tried to touch something it wasn't supposed to. At this point, a reboot is just as advisable as it is without the protection. Not that a dual-universe system, with some programs running protected and others running unprotected, is worthless. It doesn't stop the programs in the unprotected half of the world from taking out your system, but it'll stop programs running in protected mode from doing so. That provides a great incentive to purchase programs written that way, which will provide an incentive to develop programs that work in a protected environment. <mike -- He was your reason for living Mike Meyer So you once said mwm@relay.pa.dec.com Now your reason for living decwrl!mwm Has left you half dead
hamish@waikato.ac.nz (08/17/90)
In article <900816.150215.CDT.C506634@UMCVMB.MISSOURI.EDU>, C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) writes: > On 10 Aug 90 19:56:24 GMT Valentin Pepelea said: >>Another problem is that even if you provide the possiblity for new applications >>to run protected within the environment, the fact that older programs cann >>still >>jog around the address space and wreak havoc, defeats the initial purpose. >>Either you provide memory protection to everybody simultaneoulsy, or you >>don't at all. > Obviously we can't provide memory protection to everybody simultaneously. For > the forseable future there will always be old programs that will not work > properly with memory protection and people that want to run them. However, > memory protection is too valuable to just write off. > > As has been mentioned before (I beleive) The operating system and unprotected > programs could be lumped together. Protected programs would, of course, be > isolated from each other and the OS. > I believe it too! > Now, what happens when an unprotected program tries to step on a protected. > program? I'd call that a task held. It's not very nice but at least it stops > the errant program from doing real damage. > Definitly nicer that "The GURU!" > Is this as good as "real" memory protection? No. But it's better than we have > now and starts the process going toward "real" memory protection. In the > beginning it wouldn't be much differnt than now becuase protected programs > be few. But if the memory in protected programs is larger than the OS then > errant programs will usually be stopped by protection violations. This *would* > be more stable. And as time progressed it would only get better. > All I can say, is that people who use code hunks for data ought to be punished severly. (Especially Commodore Employees). Excuses are no longer good enough. Was it Valentine who said everybody does it including him. Well I DON'T do it. CODE is CODE and DATA is DATA! Using a bad programming practice doesn't make it good or acceptable. I find now that I might have to think twice before laying out hard cash for an unprotected system, where I need security. (Appologies to Valentine if it wasn't you who said that, but it tends to get my goat when a bad programming practice is used and the defended by saying "But everbody else does it!". Sounds like my little sister caught painting on the carpet with oil based paint) > Eric Edwards: c506634 @ "The 3090. Proof that by applying state of the > Inet: umcvmb.missouri.edu art technology to an obsolete architecture, > Bitnet: umcvmb.bitnet one can achieve mediocre performance." Just my 0.02c worth! -- ============================================================================== | Hamish Marson | Internet hamish@waikato.ac.nz | | Computer Support Person | Phone (071)562889 xt 8181 | | Computer Science Department | Amiga 3000 for ME! | | University of Waikato | | ============================================================================== |Disclaimer: Anything said in this message is the personal opinion of the | | finger hitting the keyboard & doesn't represent my employers | | opinion in any way. (ie we probably don't agree) | ==============================================================================
hamish@waikato.ac.nz (08/17/90)
In article <13785@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > In article <35789@ut-emx.UUCP> lshaw@walt.cc.utexas.edu (logan shaw) writes: >> >>> Another problem is that even if you provide the possiblity for new >>> applications to run protected within the environment, the fact that older >>> programs can still jog around the address space and wreak havoc, defeats >>> the initial purpose. >> >> But they can't wreak havoc with the memory declared as protected. Granted, >> it won't be 100% safe, but it will sure be alot better than it is right now. >> >> I was under the impression that (motorola, at least) MMU's worked by setting >> certain memory pages with certain attributes (protected, etc), so the >> programs which asked for protected memory would be protected from everything, >> but older programs wouldn't be protected from newer programs. > > Not quite. Protected tasks would still have their TCB in MEMF_PUBLIC memory, > which by definition means "Go ahead, stomp on me!" Ditto for memory lists > message ports, messages, I/O requests, etc. If you cannot provide 100% memory > protection and recoverability, then you might as well not provide it at all. > Don't see why. Other tasks don't have to write to it, they can go through the system to do anything that has to be done to another task. The system allocates memory, so the memory lists can be protected. Message ports, well I use the system to pass a message. If you don't, then whats it there for? Show? To take up space in the ROM? > You might disagree, but remember, I'm always right. ;-) > A matter of opinion. (Not mine) >> It can't be _that_ difficult to write. PLEASE can we have this in 2.1? >> Please, please, please? Pretty please with syntactic sugar on top of it? > > As I have said before, the technical difficulties are not what is keeping us > from coming out with incredibly useful enhancements. You have to factor in the > energy constant, the resistance ratio and the friction coefficient. I found > out the hard way. > >> Just _once_ i'd like to see a requestor like this: >> /---------------------------------------\ >> | CLI Process 2 tried to hose Process 3 | >> | | >> | /--------\ /--------\ /-------\ | >> | | Freeze | | Ignore | | Reset | | >> | \--------/ \--------/ \-------/ | >> \---------------------------------------/ > > Indeed, coming out with a fully memory protected operating system which > protects even old software, but remains compatible by presenting one of these > requesters every time an illegal access happens, is technically possible. > But these requesters would pop up several times per second, and would leave > novice users rather confused. Don't care about all old software, just the well behaved stuff. Misbehaved software will soon be upgraded if they want it to be used. > > Another option would be to come up with an operating system that provides > full memory protection, but would allow the user to turn it on only optionally. > Easy. But to evaluate the likelyhood of such a thing happening, you have to > factory in the energy constant, the resistance ratio and the friction > coefficient... > Good. Do it. :) > Valentin > -- > The Goddess of democracy? "The tyrants Name: Valentin Pepelea > may distroy a statue, but they cannot Phone: (215) 431-9327 > kill a god." UseNet: cbmvax!valentin@uunet.uu.net > - Ancient Chinese Proverb Claimer: I not Commodore spokesman be -- ============================================================================== | Hamish Marson | Internet hamish@waikato.ac.nz | | Computer Support Person | Phone (071)562889 xt 8181 | | Computer Science Department | XXXXXXXXXXXXXXXXXXXXXXXXXX | | University of Waikato | | ============================================================================== |Disclaimer: Anything said in this message is the personal opinion of the | | finger hitting the keyboard & doesn't represent my employers | | opinion in any way. (ie we probably don't agree) | ==============================================================================
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/17/90)
In article <1248.26cbc22c@waikato.ac.nz> hamish@waikato.ac.nz writes: > > (Appologies to Valentine if it wasn't you who said that, but it tends to > get my goat when a bad programming practice is used and the defended by > saying "But everbody else does it!". Sounds like my little sister caught > painting on the carpet with oil based paint) There are few ways one can insult me, since I am well aware of the debating nature and purpose of Usenet. But mispelling my name is one of them. Asking Amiga programmers to immediately stop putting data in code hunks is like asking Unix programmers to always free all their memory before exiting a program. In both cases, programmers know that they will never be prevented from doing what they do, and in both cases they are right. Now guys, don't try to convice me otherwise because I already agree with you. It's just that I can't do anything about it. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
peter@sugar.hackercorp.com (Peter da Silva) (08/18/90)
In article <13858@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: > Asking Amiga programmers to immediately stop putting data in code hunks is like > asking Unix programmers to always free all their memory before exiting a > program. What's wrong with that? *I* always free all my memory before exiting a program (well, I leave it up to "exit()" to free memory that stdio has allocated) simply because I write re-usable routines: I expect that they may be used in a program that *doesn't* exit on an error. Say, an interactive one. What gets *MY* goat are the folks writing code for BSD that refuse to check the return status of malloc() because "with VM, it never fails". Crap. > Now guys, don't try to convice me otherwise because I already agree with you. > It's just that I can't do anything about it. If *I* can do something about it, simply by doing the right thing, why can't you? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
hamish@waikato.ac.nz (08/21/90)
In article <13858@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > In article <1248.26cbc22c@waikato.ac.nz> hamish@waikato.ac.nz writes: >> [DELETED] > > There are few ways one can insult me, since I am well aware of the debating > nature and purpose of Usenet. But mispelling my name is one of them. > Sorry bout that! > Asking Amiga programmers to immediately stop putting data in code hunks is like > asking Unix programmers to always free all their memory before exiting a > program. In both cases, programmers know that they will never be prevented > from doing what they do, and in both cases they are right. > Not really. On Unix, the system will do something about it, and it doesn't matter. On the AMiga, it's just a lazy (and bad) programming practice. It's not hard to put the damn things in a data hunk now is it? > Now guys, don't try to convice me otherwise because I already agree with you. > It's just that I can't do anything about it. > Never say "I can't". Powered, heavier than air flight was impossible until Richard Pearce came along as well. > Valentin > -- > The Goddess of democracy? "The tyrants Name: Valentin Pepelea > may distroy a statue, but they cannot Phone: (215) 431-9327 > kill a god." UseNet: cbmvax!valentin@uunet.uu.net > - Ancient Chinese Proverb Claimer: I not Commodore spokesman be How much is SysV for the Amy anyway. It seems to be the only way I'll ever get a stable system on one. Then again I could just buy a Sparc :) -- ============================================================================== | Hamish Marson | Internet hamish@waikato.ac.nz | | Computer Support Person | Phone (071)562889 xt 8181 | | Computer Science Department | Amiga 3000 for ME! | | University of Waikato | | ============================================================================== |Disclaimer: Anything said in this message is the personal opinion of the | | finger hitting the keyboard & doesn't represent my employers | | opinion in any way. (ie we probably don't agree) | ==============================================================================
charles@hpcvca.CV.HP.COM (Charles Brown) (08/22/90)
>> Asking Amiga programmers to immediately stop putting data in code >> hunks is like asking Unix programmers to always free all their >> memory before exiting a program. > What's wrong with that? *I* always free all my memory before exiting a > program (well, I leave it up to "exit()" to free memory that stdio has > allocated) simply because I write re-usable routines: I expect that > they may be used in a program that *doesn't* exit on an error. Say, an > interactive one. > -- > Peter da Silva. `-_-' In Unix it is slower because the system can release all that memory much faster than you can. Thats because it releases all of it at once rather than releasing each separately malloc'ed portion. At least this is what I understand from what a friend told me. He knows much more about Unix than I do. The only reason I was concerned about this is because on the Amiga you *must* deallocate all that RAM because the system does not implement resource tracking. I mentioned to him that I intended to do this in all my code. He told me it was a bad idea for code which would be used on Unix. So now the best solution I know of is to place this within #ifdef's which include the deallocation only if the target machine is an Amiga. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
a218@mindlink.UUCP (Charlie Gibbs) (08/22/90)
In article <1410050@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >The only reason I was concerned about this is because on the Amiga you >*must* deallocate all that RAM because the system does not implement >resource tracking. I mentioned to him that I intended to do this in >all my code. He told me it was a bad idea for code which would be >used on Unix. So now the best solution I know of is to place this >within #ifdef's which include the deallocation only if the target >machine is an Amiga. Being relatively new to Unix, I'm curious about this. Is it really that much of a Bad Thing to clean up after yourself, or are we falling into the trap of quibbling over a few milliseconds when our time would be better spent elsewhere? Just on general principles, I like to leave things as I found them. Besides, if time was critical, I would probably be using static memory anyway (no pun intended). So could a Unix guru please enlighten me? Is it actually considered evil to free memory yourself, or is it one of those conventions that just grew? Charlie_Gibbs@mindlink.UUCP I'm trying to develop a photographic memory.
new@ee.udel.edu (Darren New) (08/22/90)
In article <1410050@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >The only reason I was concerned about this is because on the Amiga you >*must* deallocate all that RAM because the system does not implement >resource tracking. Of course, the compilers do indeed implement resource tracking. If you are writing code that you will run on both Unix and the Amiga, you will probably be using malloc(), free(), fopen(), fclose(), and so on. All the C compilers on the Amiga implement these and track the resources you use so that exit() will free the resources. Don't sweat it. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
jmeissen@oregon.oacis.org ( Staff OACIS) (08/22/90)
In article <1410050@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: > >In Unix it is slower because the system can release all that memory >much faster than you can. Thats because it releases all of it at once >rather than releasing each separately malloc'ed portion. > : >The only reason I was concerned about this is because on the Amiga you >*must* deallocate all that RAM because the system does not implement >resource tracking. I mentioned to him that I intended to do this in >all my code. He told me it was a bad idea for code which would be >used on Unix. This is a ridiculous statement. It is never a bad idea for a program to track its own memory usage. I little extra work, perhaps. Given the speed of modern day Unix systems, a few extra milliseconds overhead to explicitly free memory when the program exits is not going to be significant, or even noticable. The other side of this is that a program that is written efficiently for the Amiga is generally never going to run on a Unix machine. There is a very restricted class of software (strictly file I/O, command-line based, no user interaction) that, when done right, looks the same on both machines. And even then, it's usually possible to take advantage of Amiga-specific features to make it smaller and faster. -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
pds@quintus.UUCP (Peter Schachte) (08/23/90)
In article <13756@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >Either you provide memory protection to everybody simultaneoulsy, or you >don't at all. I find that for the most part, when my Amiga crashes, it's the fault of the program I'm testing. If there were a way to run just one program protected, even if it slowed it down by a factor of 2, it'd be a BIG help to developers (and users of PD (or even commercial) software). A facility need not be a total solution in order to be useful (though, of course, a total solution that didn't slow things down or break anything would be nicer :-). -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
peter@sugar.hackercorp.com (Peter da Silva) (08/23/90)
In article <1410050@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: > > What's wrong with that? *I* always free all my memory before exiting a > > program (well, I leave it up to "exit()" to free memory that stdio has > > allocated) simply because I write re-usable routines... > In Unix it is slower because the system can release all that memory > much faster than you can. Yes, this is true. And if you use "malloc" to allocate memory on the Amiga it's true there as well. *but* eventually you're going to use that routine in an interactive application... or just one that runs long enough for the memory leak to be noticed... and it'll come back to bite you. > The only reason I was concerned about this is because on the Amiga you > *must* deallocate all that RAM because the system does not implement > resource tracking. So use "malloc". Particularly given the following: > I mentioned to him that I intended to do this in > all my code. He told me it was a bad idea for code which would be > used on Unix. Use malloc and you can be as sloppy as you want... portable code should use malloc anyway, since AllocMem isn't in P1003.1 or X3.159 (:->). But beware that you're setting yourself up for problems somewhere down the road. Some people writing for BSD UNIX don't check the return value from malloc, either. That doesn't mean it's a good idea. You can always "#define free() /* nothing */". -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (08/23/90)
One more comment on the overhead of malloc and free. "Tracers" uses malloc and free internally, and still runs fast enough that it's unplayable at 21 volts on a standard A1000. Any time you're using malloc the free will be lost in the noise. If speed is that important you should probably be using a more efficient memory management mechanism than malloc anyway, like a set of fixed size buffer pools or something. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (08/23/90)
In article <588@oregon.oacis.org> jmeissen@oregon.oacis.org ( Staff OACIS) writes: > The other side of this is that a program that is written efficiently for > the Amiga is generally never going to run on a Unix machine. That depends on the encapsulation you do, doesn't it? There are at least two portable window libraries I know of, but neither has been ported to the Amiga yet. You could try downloading stdwin from uunet!~/amiga-sources and doing a port... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
gilham@csl.sri.com (Fred Gilham) (08/23/90)
Charlie Gibbs writes:
----------------------------------------
So could a Unix guru please enlighten me? Is it actually
considered evil to free memory yourself, or is it one of those
conventions that just grew?
----------------------------------------
I'm not claiming to be a unix guru, just the voice of experience.
When I came to my current job I inherited a piece of software that
generates expert systems. I started using these expert systems to
process large quantities of events, and ended up dumping 32 meg cores.
It turned out that there were memory leaks (failure to free() after
malloc()) and also the expert systems didn't check all their calls to
malloc() to make sure they succeeded. The result was that the virtual
memory would be exhausted, malloc would return NULL, the program would
try to use the NULL value as a real address, and the program would get
aborted and write out a core file.
Moral: Someone might use your program to do real work. Make sure you
handle memory correctly.
--
Fred Gilham gilham@csl.sri.com
The emotional quality of what we moderns call our thought produces an
extreme violence of conviction combined with extreme incoherence in
our arguments. --Jacques Ellulpl@etana.tut.fi (Lehtinen Pertti) (08/23/90)
From article <2905@mindlink.UUCP>, by a218@mindlink.UUCP (Charlie Gibbs): > In article <1410050@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM > (Charles Brown) writes: > > Is it actually considered evil to free memory yourself, > or is it one of those conventions that just grew? > For me it's very natural to free all my memory after use, but in UNIX forgetting to do so does not lead to missing memory blocks. System anyway releases all resources it has given to process. malloc/free only allocate/release memory already owned by process, and if they run out of memory, they ask more with system call (sbreak). So every call to malloc/free doesn't (in UNIX) lead to system call and so it is quite efficient there. -- pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
charles@hpcvca.CV.HP.COM (Charles Brown) (08/24/90)
First I want to thank those people who pointed out that the current Amiga compilers perform the memory tracking as long as I use malloc(). I hadn't known that. >> In Unix it is slower because the system can release all that memory >> much faster than you can. Thats because it releases all of it at once >> rather than releasing each separately malloc'ed portion. >> : >> The only reason I was concerned about this is because on the Amiga you >> *must* deallocate all that RAM because the system does not implement >> resource tracking. I mentioned to him that I intended to do this in >> all my code. He told me it was a bad idea for code which would be >> used on Unix. > This is a ridiculous statement. It is never a bad idea for a program to > track its own memory usage. I little extra work, perhaps. Given the speed > of modern day Unix systems, a few extra milliseconds overhead to explicitly > free memory when the program exits is not going to be significant, or even > noticable. Be careful what you call rediculous. You are telling me that I should put in extra code making the program take longer to write, take more space on disk and in RAM, take longer to run, and for what? You have mentioned no advantages. The only argument you offer in favor of your approach ("It is never a bad idea"..) seems to be strictly religious. > The other side of this is that a program that is written efficiently for > the Amiga is generally never going to run on a Unix machine. There is a > very restricted class of software (strictly file I/O, command-line based, > no user interaction) that, when done right, looks the same on both > machines. And even then, it's usually possible to take advantage of > Amiga-specific features to make it smaller and faster. > -- > John Meissen .............. Oregon Advanced Computing Institute Perhaps I'm old fashioned. I still find programs like sed, awk and perl useful. In fact the program which I was talking about when I first jumped into this notes string was a filter with no user interaction. It is designed strictly for doing math on an input file, in the same sense that sed does string substitutions on an input file. Sometimes I want the computer to perform a task *without* interaction. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer. "The guy sure looks like plant food to me." Little Shop of Horror
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (08/24/90)
>>>>> On 21 Aug 90 21:43:52 GMT, a218@mindlink.UUCP (Charlie Gibbs) said:
Charlie> Being relatively new to Unix, I'm curious about this. Is it
Charlie> really that much of a Bad Thing to clean up after yourself, or are
Charlie> we falling into the trap of quibbling over a few milliseconds when
Charlie> our time would be better spent elsewhere?
99.9% of the time, it's best to free() everything you can before starting
another round of malloc()s. (Duh!-) Explictly free()ing memory before
exit()ing is unecessary under UNIX, _BUT_ today's application often winds
up tomorrow's subroutine. If you don't at least write the code for
explicit free()ing with #ifdefs around it, you may have to come back a year
or so later and try to figure out how best to patch it in so your new mega
application doesn't leak memory all over the carpet when your (now)
subroutine gets invoked repeatedly.
If rapid (de)allocation of memory is paramount, you shouldn't use malloc()
or free() at all. The traditional UNIX way is to sbrk() large chunks and
explicitly manage the space yourself. HOWEVER, System Vr4 has mmap().
(Concieved at Berzerkely, implemented by Sun, I believe. Thanks, guys!)
Some mmap() Advantages:
1. You can release mmap()ed memory back to the OS for reuse by
other proceses, unlike sbrk() or malloc(), which typically calls
sbrk().
2. You can mmap() a disk file into memory, allowing you to
access it just like RAM.
3. Multiple processes can mmap() the same file into their address
space for clean shared memory, compared to shm*() memory IMHO.
4. mmap()ed memory can be marked "copy on write" so that multiple
processes copy only modified parts of an mmap()ed file into
their own process space on a page-by-page basis. (Typical UNIX
page sizes run 2-8KB.)
5. mmap() memory can be explicitly marked for read, write and
execute permissions on a process-by-process basis.
There are other reasons, like performance. These are just off the top of
my head.
Hope this helps,
--
Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
2001 Danfield Ct.
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckpp554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/25/90)
In article <1410051@hpcvca.CV.HP.COM> charles@hpcvca.CV.HP.COM (Charles Brown) writes: >Be careful what you call rediculous. You are telling me that I should >put in extra code making the program take longer to write, take more >space on disk and in RAM, take longer to run, and for what? You have >mentioned no advantages. The only argument you offer in favor of your >approach ("It is never a bad idea"..) seems to be strictly religious. That's the same argument that forbids sanity checks on input and we know how much you can win by just adding some lines of code. Nevertheless, if resource tracking is done, then it has to be done somewhere in memory. If you don't allocate the space for resource tables then the system has to do so, and it might use even more since it has to deal with all potential resources your task may allocate. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
andrew@teslab.lab.OZ (Andrew Phillips 289 8712) (08/28/90)
In article <2905@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >.... > So could a Unix guru please enlighten me? Is it actually >considered evil to free memory yourself, or is it one of those >conventions that just grew? Its not evil but I think its more a matter of laziness. Keeping track of what memory was allocated can become tricky particularly if you have an unrecoverable error (in which case you normally just print a message and exit()). Saying it is more efficient is merely a justification for sloppy coding. As for why you should free all memory. Apart from the fact that your program may be used as a subroutine as already mentioned, it makes it easier to understand the code and maintain it. For example, it is unclear whether the memory is still allocated at the end of the routine or has been released by a routine at a lower level. So I believe you should allocate and free all memory (and other resources) in the same routine or in paired routines of the same level. Andrew. -- Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 289 8712
jdresser@altair.uucp (Jay Dresser) (08/30/90)
My solution to lost memory was rather straightforward. I allocate memory through my routines which alloc from chunks I get from AllocEntry. I then append the MemEntry to the list maintained in the Task structure. This memory is automatically freed by the system when the task exits. Thus no more lost memory. This seems to me the way it was meant to be. This I wrote after implementing a more general cleanup system that keeps track of alloced memory, open files, open libraries, or anything else that needs to be undone when exiting. I never have any hanging anything. Jay
charles@hpcvca.CV.HP.COM (Charles Brown) (08/31/90)
>> So could a Unix guru please enlighten me? Is it actually >> considered evil to free memory yourself, or is it one of those >> conventions that just grew? > Its not evil but I think its more a matter of laziness. Keeping > track of what memory was allocated can become tricky particularly if > you have an unrecoverable error (in which case you normally just > print a message and exit()). Saying it is more efficient is merely a > justification for sloppy coding. > -- > Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) I think this notes string has turned religeous. Since I was the one who spoke of the desirability of not freeing memory, I will attempt to put my comments into some perspective. Certainly it is not evil. If I could have seen any benefit to doing so in the application I wrote I would have done so. But like so many things in life, it depends upon the circumstance. In my program there was no possibility of freeing or reusing memory until the program was ready to exit. In that case it would be stupid (rather than lazy) to put in the extra code since it would make the program bigger and cause it to run (slightly) slower. This is not the same as error checking. I never skimp on checking; I just don't trust the user or the system enough for that. And I expect my software to recover gracefully from my errors. If I encapsulate the symbol table (which is what was malloc'ing memory in the above program) into another application which may want to free memory then it will certainly be desirable to provide the code to free that memory. At that time I will. Until then it would be a waste of time and space. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!"