billc@percival.UUCP (William Coldwell) (09/07/88)
How come the IEEE libraries when installed are set to -1 whether they are
being used or not? I would like to flush them if they are not being used,
but I would also like to know what program is using them at the time...
Bill
[Yes, I know I ask the strangest questions....]
--
William J. Coldwell - Amiga Attitude Adjuster {aka Software Developer}
(503) 684-9300 ...tektronix!reed!percival!billc "Blame the hardware."
[I break for 14MHz Processor Accelerators with 68881's.]
Creative Microsystems Inc. / 10110 SW Nimbus Suite B1 / Portland, OR 97223kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/07/88)
In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: >How come the IEEE libraries when installed are set to -1 whether they are >being used or not? I would like to flush them if they are not being used, >but I would also like to know what program is using them at the time... This is a bug in someone's code (maybe your's). Someone has closed the IEEE library one more time than they opened it. In my case here is what happened: 1. I open the IEEE library myself, since Manx crashes the machine if you don't have the library in your LIBS directory. 2. I put the library pointer into the same global library pointer that Manx uses so that Manx does not open the library also. 3. I use the library. 4. I CloseLibrary() the IEEE library since I opened it. 5. Manx looks at the global library pointer, if it is NULL then it presumes that it never opened the library and does not close it. If the global library pointer is not NULL, then Manx presumes it opened it and CloseLibrary()'s the IEEE lib. The result of the above is that the IEEE lib is closed one more time than it was opened. Thus a minus one for open count instead of 0. This results in a time bomb waiting to go off: 1. I open the IEEE library again and the open count goes to 0. (which means the system can remove the library at it's discression). 2. Someone malloc (or AllocMem's) lot's of memory and the system removes the IEEE library to get more RAM. 3. My code does an IEEE operation and crashes with random gurus because the library is gone. So if you are working with Manx (maybe lattice too) and you are explicitly opening the IEEE library, then when you close the library, set the global library pointer to NULL (so Manx doesn't close it a second time). I wrote Dale Luck about this bug and he says it's a Manx bug. I think that the CloseLibrary code should never let the open count go negative, but I was unable to convince Dale of this. So you must fix it yourself. > > Bill > [Yes, I know I ask the strangest questions....] Strange questions are appropriate for strange bugs 8^). I presume you are writing your own code that is causing this. If not, then try to isolate the code that you use that causes the bug, and call the company that wrote it and complain. This kind of bug can make other people's code look bad. This is another good reason not to have a finger pointing requester with GURU's and task helds. > William J. Coldwell - Amiga Attitude Adjuster {aka Software Developer} -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
dale@boing.UUCP (Dale Luck) (09/08/88)
In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: > >How come the IEEE libraries when installed are set to -1 whether they are >being used or not? I would like to flush them if they are not being used, >but I would also like to know what program is using them at the time... > Maybe you are looking at the trans library? It opens the bas library when it is loaded. So you may have to "flush twice." -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
dale@boing.UUCP (Dale Luck) (09/08/88)
In article <b03Kac9bnd10108qAIk@amdahl.uts.amdahl.com> kevin@amdahl.uts.amdahl.com (Kevin Clague) writes: >In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: > > >So if you are working with Manx (maybe lattice too) and you are >explicitly opening the IEEE library, then when you close the library, >set the global library pointer to NULL (so Manx doesn't close it a >second time). > >I wrote Dale Luck about this bug and he says it's a Manx bug. I think >that the CloseLibrary code should never let the open count go negative, >but I was unable to convince Dale of this. So you must fix it yourself. > It is definately a Manx bug. However CloseLibrary not letting the Opencount go negative and returning would only postpone an inevitable crash. The fact is, the program opened the library once and now closed it twice. Very Bad. The one change we could make for V1.4 is have it GURU (recoverable?) when the opencount goes negative. The system is definately sick and we cannot continue normal operation of the system software. If someone else has the library open and tries to access it when your manx program has just caused a flush would result in fire works also. A more complex change would be the ieee library keeping a table of what tasks have opened the library. It could then keep a global count in the standard place, and when an individual task closes, make sure it is not doing something bad. It could then at least insure the correctness of master opencount. -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
root@sbcs.sunysb.edu (root) (09/08/88)
In article <358@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > In article <b03Kac9bnd10108qAIk@amdahl.uts.amdahl.com> kevin@amdahl.uts.amdahl.com (Kevin Clague) writes: > >In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: > > > > > >So if you are working with Manx (maybe lattice too) and you are > >explicitly opening the IEEE library, then when you close the library, > >set the global library pointer to NULL (so Manx doesn't close it a > >second time). > > > >I wrote Dale Luck about this bug and he says it's a Manx bug. I think > >that the CloseLibrary code should never let the open count go negative, > >but I was unable to convince Dale of this. So you must fix it yourself. > > > It is definately a Manx bug. However CloseLibrary not letting the > Opencount go negative and returning would only postpone an inevitable > crash. The fact is, the program opened the library once and now closed > it twice. Very Bad. > > The one change we could make for V1.4 is have it GURU (recoverable?) No, please no more GURU conditions. It seems to be that a reasonable thing to do is when the count would go negative just mark the library as permanently open and ignore any further closes. I've seen plenty of programs do eg, more closes() than open()'s as part of badly written cleanup code - under systems like Unix the first close() sticks and the others just return a -1. Crashing the system (ie giving the Amiga BAD PRESS) is just bad form for announcing such a condition. When our network code lived as a library rather than its current handler form we made some effort to be robust under too many CloseLibrary()'s - it can be a comment mistake. > A more complex change would be the ieee library keeping a table of > what tasks have opened the library. It could then keep a global count > in the standard place, and when an individual task closes, make sure > it is not doing something bad. It could then at least insure the > correctness of master opencount. Too complicated. > > -- > Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Rick Spanbauer Ameristar Technology
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/08/88)
In article <358@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > The fact is, the program opened the library once and now closed >it twice. Very Bad. agreed! > >The one change we could make for V1.4 is have it GURU (recoverable?) >when the opencount goes negative. The system is definately sick and >we cannot continue normal operation of the system software. If someone >else has the library open and tries to access it when your manx program >has just caused a flush would result in fire works also. Better than finding out the hard way. I wouldn't have found it if I hadn't been using AmigaMonitor (or looked at the open lib count). > >A more complex change would be the ieee library keeping a table of >what tasks have opened the library. It could then keep a global count >in the standard place, and when an individual task closes, make sure >it is not doing something bad. It could then at least insure the >correctness of master opencount. Sounds far too complex. Nothing, or the recoverable GURU sounds better. -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
jones@ingr.UUCP (Mark Jones) (09/08/88)
> > A more complex change would be the ieee library keeping a table of > what tasks have opened the library. It could then keep a global count > in the standard place, and when an individual task closes, make sure > it is not doing something bad. It could then at least insure the > correctness of master opencount. > This would be a very good Idea, It could be put in OpenLibrary, and CloseLibary and be a way to prevent opening or closing the library more than once from one program. Also, when a task craps out, the library lists could be scanned and the libraries closed accordingly. This would give the Amiga a more robust interface to keep bad programs from making the hardware look bad. While were at this list keeping business, how about tracking memory allocations, and deallocating the blocks when the run is over? I know this might add some overhead to allocations and frees, but I think it would be worth it. Mark Jones Isn't it great that opinions are FREE!
andy@cbmvax.UUCP (Andy Finkel) (09/09/88)
In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: > >How come the IEEE libraries when installed are set to -1 whether they are >being used or not? I would like to flush them if they are not being used, >but I would also like to know what program is using them at the time... Check what the startup code that the compiler (and/or linker) is attaching to your program is doing to/for you. This can often be quite educational. These days it seems a lot of startup code is doing too much for my taste...declaring library bases, opening and closing libraries automatically, etc. You are probably running into one of these cases. If not, its still pretty interesting, seeing what is being added to your program. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If we can't fix it, it ain't broke." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dale@boing.UUCP (Dale Luck) (09/10/88)
In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >> >> The one change we could make for V1.4 is have it GURU (recoverable?) > > No, please no more GURU conditions. It seems to be that a reasonable > thing to do is when the count would go negative just mark the > library as permanently open and ignore any further closes. ok, how about this. I give pm an arex port. And I also let pm display messages sent to him via arex. When the library detects an illegal condition it sends a string to pm and pm puts it up. The library itself cannot put up the message since it does not open any other libraries, nor does it have control over how much stack it was given. Couple more questions. Do I just wait till opencnt goes negative globally? Or should the library track particular tasks. If I track particular tasks should I automatically close the library for that task if it disappears from the system? Or maybe I should just send another message stating that a task was lost. -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/10/88)
In article <362@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >>> >>> The one change we could make for V1.4 is have it GURU (recoverable?) >> >> No, please no more GURU conditions. It seems to be that a reasonable >> thing to do is when the count would go negative just mark the >> library as permanently open and ignore any further closes. > >ok, how about this. I give pm an arex port. And I also let pm display >messages sent to him via arex. When the library detects an illegal >condition it sends a string to pm and pm puts it up. The library itself >cannot put up the message since it does not open any other libraries, nor >does it have control over how much stack it was given. Interesting idea. I never would have thought about it. > >Couple more questions. >Do I just wait till opencnt goes negative globally? Or should the library >track particular tasks. Danger Will Robinson... resource tracking ahead. It depends on how complex the implementation is. Task tracking has it's advantages. > >If I track particular tasks should I automatically close the library >for that task if it disappears from the system? Or maybe I should just >send another message stating that a task was lost. Sounds like you may be setting a precedent for other libraries to follow >Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale >Although I do contract work for Amiga-LosGatos, my opinions probably >don't represent those of Commodore or its management or its engineers, >but I think the world would be a better place if they did. GOT THAT RIGHT!! kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
charles@hpcvca.HP.COM (Charles Brown) (09/10/88)
> The one change we could make for V1.4 is have it GURU (recoverable?) > when the opencount goes negative. The best solution would be to kill the program which requested this. Occasionally it would kill the wrong process, but usually the right one would be killed. Either way, the problem could be identified as soon as possible. The chances of the bug being caught and fixed would thus be maximized. Unfortunately, AmigaDos is not capable of doing this. :-( The next best solution is to recoverably Guru. The worst solution is to continue operating as tho nothing bad had happened. > A more complex change would be the ieee library keeping a table of > what tasks have opened the library. > Dale Luck This solution looks so complex that it is likely to create additional problems that we cannot even imagine. Charles Brown
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/11/88)
In article <362@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >>> >>> The one change we could make for V1.4 is have it GURU (recoverable?) >> >> No, please no more GURU conditions. It seems to be that a reasonable >> thing to do is when the count would go negative just mark the >> library as permanently open and ignore any further closes. > >ok, how about this. I give pm an arex port. And I also let pm display >messages sent to him via arex. When the library detects an illegal >condition it sends a string to pm and pm puts it up. The library itself >cannot put up the message since it does not open any other libraries, nor >does it have control over how much stack it was given. One solution that is not exactly elegant, and certainly doesn't solve all the problems is to at least make sure that when someone opens the IEEE libs the opencnt is at least one. If I run a broken program and it doubly closes the IEEE libs, then opencnt is -1. If I run this again then opencnt is < 1, at least force it to 1. This may not handle all the cases, but might help in some. >Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale kev -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
dale@boing.UUCP (Dale Luck) (09/11/88)
In article <b2tJd455u610103u.iI@amdahl.uts.amdahl.com> kevin@amdahl.uts.amdahl.com (Kevin Clague) writes: > >One solution that is not exactly elegant, and certainly doesn't solve >all the problems is to at least make sure that when someone opens the >IEEE libs the opencnt is at least one. > >If I run a broken program and it doubly closes the IEEE libs, then opencnt >is -1. If I run this again then opencnt is < 1, at least force it to >1. This may not handle all the cases, but might help in some. > I don't think this is a good idea. If the opencnt ever goes negative because of too many Closes, it is clearly an error condition. The sooner we find out about error conditions the better. I believe some sort of report must be generated when the opencnt goes negative. This would prevent the case of a negative open count causing an expunge by having the library reopened and a subsequent expunge call performed when we run out of memory. -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
shf@well.UUCP (Stuart H. Ferguson) (09/13/88)
| In article <358@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: | > In article <b03Kac9bnd10108qAIk@amdahl.uts.amdahl.com> kevin@amdahl.uts.amdahl.com (Kevin Clague) writes: | > >In article <1356@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: | > >I wrote Dale Luck about this bug and he says it's a Manx bug. I think | > >that the CloseLibrary code should never let the open count go negative, | > >but I was unable to convince Dale of this. So you must fix it yourself. | > It is definately a Manx bug. However CloseLibrary not letting the | > Opencount go negative and returning would only postpone an inevitable | > crash. The fact is, the program opened the library once and now closed | > it twice. Very Bad. | > | > The one change we could make for V1.4 is have it GURU (recoverable?) | | No, please no more GURU conditions. I don't see a reason to react so strongly against GURU conditions. It is the only way the Amiga has to protect herself from bogus programs suffering themselves upon her. Since there is no MMU and no resource tracking to speak of, what else should she do when some errant program has effectivly spoiled the fun for everybody by doing something harmful to the integrity of the system itself? | [ ... ] It seems to be that a reasonable | thing to do is when the count would go negative just mark the | library as permanently open and ignore any further closes. Except that this doesn't fix the problem. You correct the error only *after* the open count goes negative. This means that it went through zero while the library may still be open. If it was removed while the count was zero you'll get a GURU anyway. | [ ... ] I've | seen plenty of programs do eg, more closes() than open()'s as part | of badly written cleanup code - under systems like Unix the first | close() sticks and the others just return a -1. Crashing the | system (ie giving the Amiga BAD PRESS) is just bad form for | announcing such a condition. The reason that programs behave badly (or what would be badly on the Amiga) is that they can get away with it. For this particular case, I would vote for a GURU, even a non-recoverable one, so that the error can be discovered during development, and not at that one critical time sometime after the program is out. This particular condition (i.e. closing the library too often) will be discovered immediately during testing if it causes a GURU. | [ ... ] When our network code lived as | a library rather than its current handler form we made some effort | to be robust under too many CloseLibrary()'s - it can be a comment | mistake. Again, just because it's a common mistake doesn't make it right. It can KILL the system, no matter how robust you try to be about it. The more robust you try to be, the more obscure you make the times when it does fail. I would rather have it fail outright to make it easier on the developer. Dale did suggest that this be a recoverable GURU. The recovery could be as suggested -- to make the library permanently open. After the GURU and this recovery have happened, the system is safe. The problem is before the error is discovered when the open count is wrongly zero. | > A more complex change would be the ieee library keeping a table of | > what tasks have opened the library. It could then keep a global count | > in the standard place, and when an individual task closes, make sure | > it is not doing something bad. It could then at least insure the | > correctness of master opencount. | Too complicated. And it won't work either. The problem is, of course, that the library doesn't have to be opened and closed by the same task. The library base pointer could have transfered ownership in a message pass. And don't say, "That would never happen," because I have a real case where it does (not for the IEEE library, however, but I don't like this type of precedent). -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
rminnich@super.ORG (Ronald G Minnich) (09/14/88)
In article <7096@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >I don't see a reason to react so strongly against GURU conditions. It There is just one reason. when people see them they get upset, esp. people like J Pournelle who, like it or not, really can affect how many amiga's get purchased. I really agree with Rick on this one. Think of the GURU as really bad PR (which it is) which can adversely affect amiga's sales. Dale makes a good point that the code SHOULD be perfect. But we all know (or at least i think i know) how likely this is. If the tradeoff is slow suffocation (libraries hanging around that are no longer open) vs. even a recoverable GURU, i vote for suffocation. With the 1mb minimum common on most machines i don't see that a few extra open libraries will kill you. But too many GURUs will kill amiga sales. God i wish they hadn't called it a guru. I get so sick of the jokes about that one ... Now a library could attempt to keep track of when bogosity occurs. That's a whole nother issue. and of course the right answer is resource tracking. But we have to use what we have, not what we should have. ron
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (09/14/88)
In article <362@boing.UUCP>, Dale Luck (dale@boing.UUCP) writes: > [ other writers' comments ] > ok, how about this. I give pm an arex port. And I also let pm display > messages sent to him via arex. When the library detects an illegal > condition it sends a string to pm and pm puts it up. The library itself > cannot put up the message since it does not open any other libraries, nor > does it have control over how much stack it was given. This is fine, but an alert or a guru would ensure that the programmer will pay attention to his errors! I know there are some who don't want to see any more guru messages, but the libraries should complain bitterly the moment this happens! Otherwise, there will be just that many more broken pieces of software out floating around. . . > Couple more questions. > Do I just wait till opencnt goes negative globally? Or should the library > track particular tasks. Track separate tasks! That way, the offenders will show up quickly. (In fact, it might be a good idea to put up an alert if a single task *opened* the library twice without a close in between!) > If I track particular tasks should I automatically close the library > for that task if it disappears from the system? Or maybe I should just > send another message stating that a task was lost. If the task disappears, close the library for that task. That way, the system should have the best chance of continuing to run after the rogue task has evaporated. Steve Rice ----------------------------------------------------------------------------- * Every knee shall bow, and every tongue confess that Jesus Christ is Lord! * new: stever@videovax.tv.Tek.com [phone (503) 627-1320] old: {decvax | hplabs | uunet | uw-beaver}!tektronix!videovax!stever
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/14/88)
In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >In article <358@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: [ about toomany CloseLibrary()s ] >> The one change we could make for V1.4 is have it GURU (recoverable?) > No, please no more GURU conditions. It seems to be that a reasonable > thing to do is when the count would go negative just mark the > library as permanently open and ignore any further closes. I'd cast my vote for the GURU rather than just pretending the problem didn't happen. I'd rather see the broken software stop working than redefine the OS to make buggy programs work. Of course, I'm also one of those people that would have any read access to address 0 cause a GURU as well. > I've > seen plenty of programs do eg, more closes() than open()'s as part > of badly written cleanup code - under systems like Unix the first > close() sticks and the others just return a -1. On Unix, you can only close a file descriptor once; after that it's gone and passing the same number to close() again is comparable to doing a CloseLibrary(0x123456L) (i.e. "closing" an address which doesn't contain a library anyway). Also, this would just cause the problem to happen less often and in less tracable ways. If the library got flushed (when the count was zero) and *then* someone closed it, they would be decrementing a memory location that was then used for something completely different (perhaps part of the code segment of a newly loaded program, for example). > Crashing the > system (ie giving the Amiga BAD PRESS) is just bad form for > announcing such a condition. So complain to the programmer who crashed the system. When a library opencount goes negative it means that the system was in a vulnerable state for a non-zero amount of time. What is the real opencount? How many pointers to that library are really out there? How many times was the library flushed and relocated before the count actually went below zero? How many now-invalid pointers are there to places where the library used to be? The mere existence of a program which munges library opencounts means that anything in the system could be corrupted in a non-recoverable way, and that is justification for a Guru. >> A more complex change would be the ieee library keeping a table of >> what tasks have opened the library. [ ... ] > Too complicated. ... and inconsistent with the way everything else in Exec works. Besides, you don't have to be a task to open a library. A library might keep handles on other libraries, and you wouldn't want to attribute those handles to the task that was running at the time. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
peter@sugar.uu.net (Peter da Silva) (09/14/88)
While I agree that it's better to GURU than live with a dangerous situation, you can't just GURU on every error a programmer might make. If nothing else, it slows down debugging. For potentialy recoverable errors, how about making it a trap that something like SDB can catch... like it is for 68000 processor errors. It's so nice having it show me where my address violation is. Saved my lunch a couple of times. It may be desirable to make it even less traumatic than that. After all, there are a bunch of mistakes you can make that the Amiga software actually gives you an error code! Talk about dangerous programming! (Sarcasm mode on, in case you missed it...) Please... in some future version... resource management... -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
peter@sugar.uu.net (Peter da Silva) (09/14/88)
In article <4724@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > On Unix, you can only close a file descriptor once; after that it's > gone and passing the same number to close() again is comparable to > doing a CloseLibrary(0x123456L) (i.e. "closing" an address which > doesn't contain a library anyway). Except that it doesn't kill() your program, it just returns an error code. I just wonder why we've been so worried about making IPC safe from crazy programmers, when the system software is so dangerously open. What would it cost to use a bunch of static tables for things like file handles and libraries. Things that could be tracked. All these pointers flying around are pretty dangerous... (Marvin voice: I'm not getting you down, am I?) -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
root@sbcs.sunysb.edu (root) (09/14/88)
In article <4724@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: > >In article <358@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > > I've > > seen plenty of programs do eg, more closes() than open()'s as part > > of badly written cleanup code - under systems like Unix the first > > close() sticks and the others just return a -1. > > On Unix, you can only close a file descriptor once; after that it's > gone and passing the same number to close() again is comparable to > doing a CloseLibrary(0x123456L) (i.e. "closing" an address which With the crucial difference that Unix doesn't crash and then paste up a big advertisement stating the fact to any reviewer who has the machine :-). > > Crashing the > > system (ie giving the Amiga BAD PRESS) is just bad form for > > announcing such a condition. > > So complain to the programmer who crashed the system. When a library When the machine is in eg, JP's hands we don't have this luxury. Guilt by association. > -=] Ford [=- > . . (In Real Life: Mike Ditto) > . : , ford@kenobi.cts.com Rick Spanbauer SUNY/Stony Brook
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/14/88)
In article <731@super.ORG> rminnich@metropolis.UUCP (Ronald G Minnich) writes: >In article <7096@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >>I don't see a reason to react so strongly against GURU conditions. It >There is just one reason. when people see them they get upset, esp. >people like J Pournelle who, like it or not, really can affect >how many amiga's get purchased. I had this multiple code bug in my code for a year and didn't even know it. Once I found it, it took me a few days to shoot. Looking back, I would prefer to have had a recoverable GURU rather than no report at all. I would have known instantly that there was a bug, not a year later. I think fixing the problem is better than patching around it. > Dale makes a good point that the code SHOULD be perfect. But we >all know (or at least i think i know) how likely this is. If the >tradeoff is slow suffocation (libraries hanging around that are >no longer open) vs. even a recoverable GURU, i vote for suffocation. You are refereing to run time suffocation. Dale and Stuart are talking about long term operating system suffocation. > Now a library could attempt to keep track of when bogosity occurs. >That's a whole nother issue. and of course the right answer is >resource tracking. But we have to use what we have, not what we should >have. This is the right answer, but is a system issue, not just an IEEE library issue. >ron kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
cg@myrias.UUCP (Chris Gray) (09/15/88)
There seems to be two sides to the argument about what to do when a library
use-count goes negative. One side wants a GURU (possibly recoverable) so that
the offending program will be found quickly and fixed. The other side wants
no more GURUs, because they make the machine look bad. The solution seems to
be (to me anyway) to have a settable option that controls whether or not
non-fatal GURU's appear at all. The default would be no, for the casual user.
All developers should be hung by their toenails if they don't always run
with it set to 'yes'.
Part of the problem is a difference in philosophy, I suspect. Some people
want a perfect world with no bugs; others just want things to usually work.
I lean towards the former, personally.
--
Chris Gray Myrias Research, Edmonton +1 403 428 1616
{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cgrminnich@super.ORG (Ronald G Minnich) (09/15/88)
In article <b4mcD06KFb10108KelM@amdahl.uts.amdahl.com> kevin@amdahl.uts.amdahl.com (Kevin Clague) writes: >I had this multiple code bug in my code for a year and didn't even >know it. Once I found it, it took me a few days to shoot. Looking back, >I would prefer to have had a recoverable GURU rather than no report at Agreed that for doing a library the guru is the good thing. I maintain that guru's should be avoided for non-computer types. Well, ok, suppose we have a switch in the OS that determines whether you get the 'carry on' behavior or you get the GURU. Sort of an equivalent to loadwb -debug. Default is to get 'carry on', so that potential customers are not lost by the guru. I have seen people get really freaked out even by the 'recoverable alert' type messages ("my pc never did that!"). But, if you were a developer type yourself, you run the setguru program or something, and now you get a guru. Or is that too messy too? I don't know, i just know that 1) Perfection is impossible, and 2) GURUs really turn people off. Customer-type people, i mean. people who might buy amigas and drive unit costs down. ron
pds@quintus.uucp (Peter Schachte) (09/16/88)
In article <2627@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >What would it cost to use a bunch of static tables for things like file >handles and libraries. Please, no fixed-size tables of resources, like unix fds. Whatever number you pick, someone's bound to want more. Let the OS keep lists of active resources so it can pick up after you. Or chain the things together if you're worried about space. Resource tracking, yes. Fixed sized resource tables, no. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds