Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!hplabs!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: IEEE libraries Summary: Sometimes GURU's are good. Keywords: IEEE, GURU, Death, Horror, AINU (Amiga Is Not Unix) Message-ID: <7096@well.UUCP> Date: 13 Sep 88 09:50:22 GMT References: <1356@percival.UUCP> <358@boing.UUCP> <1570@sbcs.sunysb.edu> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Distribution: na Organization: The Blue Planet Lines: 80 | In article <358@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: | > In article 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)