eachus@mitre-bedford.ARPA (Robert Eachus) (09/13/88)
What we need is an upwardly compatible solution which does not cause existing correct programs to Guru if some other task fouls things up. The following suggestion points the way: >In article <1570@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: >> >> 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. If setting the open count negative makes a library permanently resident (at least till the next warm boot, or someone intentionally diddles the bits) we get the following rule: When a library is opened by a task, if the (open) count is non-negative, increment it by one. When a library is closed decrement the count by one. Libraries may only be unloaded when the count is zero. Simple and sweet. I like the idea of ratcheting the count down, but setting all negative counts to minus one or some other value is equally acceptable. In any case, other than to very simple OS changes, no fuss, no bother. It might be nice to add a make permanently resident call, and a force unload utility, but these are frills. And it is all very useful. A library could force itself to stay resident if it opened a resouce behind the users back when it needed to maintain state. (Such a library would have to track itself, but this shouldn't be hard if it is needed.) Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
dale@boing.UUCP (Dale Luck) (09/13/88)
In article <39822@linus.UUCP> eachus@mitre-bedford.ARPA (Robert I. Eachus) writes: > > If setting the open count negative makes a library permanently >resident (at least till the next warm boot, or someone intentionally >diddles the bits) we get the following rule: Not the present behavior of any amiga library. It is also a bad precedent to set. It should somehow tell the user/programmer that something bad has happened. However it may only be a notification and not a dead end item. > > When a library is opened by a task, if the (open) count is > non-negative, increment it by one. When a library is closed > decrement the count by one. Libraries may only be unloaded > when the count is zero. This already occurs! and it works well, it saves on memory. > > Simple and sweet. I like the idea of ratcheting the count down, >but setting all negative counts to minus one or some other value is >equally acceptable. In any case, other than to very simple OS >changes, no fuss, no bother. It might be nice to add a make >permanently resident call, and a force unload utility, but these are >frills. And it is all very useful. A library could force itself to >stay resident if it opened a resouce behind the users back when it >needed to maintain state. (Such a library would have to track itself, >but this shouldn't be hard if it is needed.) It is not a good idea to put this stuff in any of the libraries and begin a precedent of tolerating software bugs. We must strive for perfection in this operating system and associated applications or we will eventually wind up limited by our own short sightedness. If we expect to continue to make progress we must be able to count on certain activities in the os and applications. The ones that for some reason or another fail to work properly must be revved to that other applications and os software can count on well running execution environment. -- 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.
peter@sugar.uu.net (Peter da Silva) (09/13/88)
In article <39822@linus.UUCP>, eachus@mitre-bedford.ARPA (Robert Eachus) writes: > When a library is opened by a task, if the (open) count is > non-negative, increment it by one. When a library is closed > decrement the count by one. Libraries may only be unloaded > when the count is zero. Not good enough: Task A opens guru.device. Task B opens guru.device. Task B closes guru.device. Task B closes guru.device again. Memory gets low, guru.device is purged. Task A accesses guru.device. GURU MEDITATION 00000004.00C50899 The open count never went negative. The only way to do this right is to track opens on a per-task basis. This requires long-term uniqueness of task ids which the current setup doesn't allow for: that message port might end up being created in the same place as the old one. The best way to implement this would be general resource tracking. 1.5? 2.0? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
root@sbcs.sunysb.edu (root) (09/13/88)
In article <368@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > In article <39822@linus.UUCP> eachus@mitre-bedford.ARPA (Robert I. Eachus) writes: > > It is not a good idea to put this stuff in any of the libraries and > begin a precedent of tolerating software bugs. We must strive for > perfection in this operating system and associated applications or > we will eventually wind up limited by our own short sightedness. > No, relying on bug free programs for correct system operation is just bad design. Bugs exist. Bugs come into existence when the OS changes. Some bugs are created when two programs play together in some unexpected way. Some bugs are created when two pieces of hardware interact in strange ways. Some bugs even show up when the base machine is changed, ie new motherboard rev. If we have relatively inexpensive ways of riding through error/bad programming conditions they should be taken. I would say that we probably don't want to get into general argument checking, but simple, fairly low rate of occurance calls can be checked: Open*/Close* operations are always good candidates for checking. People still find bugs in VMS/Unix utilities in spite of the maturity/simplicity of at least Unix applications, so expecting more of the Amiga is unreasonable. Especially given the evolving nature of the Amiga and of course lack of memory protection, resource tracking, etc. We *should* all strive for perfection. This being the real world though, when a program falls short of our ideal the machine doesn't need to put up big BLINKING RED LIGHTS that a software error occured. Bad press for the machine and silly if a few extra bytes spent doing some minimal checking could have prevented it. I sometimes get the impression that people respect an IBM PC style crash more than "Software Error - Task held" or "GURU meditation" if for no other reason than if the Amiga is smart enough to detect the condition they ask "why can't it fix it?". Anways, that opinion is based on a very limited sample set of non computer types who've used my Amiga here. > Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Rick Spanbauer SUNY/Stony Brook
rminnich@super.ORG (Ronald G Minnich) (09/13/88)
In article <39822@linus.UUCP> eachus@mitre-bedford.ARPA (Robert I. Eachus) writes: > decrement the count by one. Libraries may only be unloaded > when the count is zero. > Simple and sweet. I like the idea of ratcheting the count down, One good reason to let the count go less than -1 is debugging. i.e. you are looking with amon, and see a library with -1 count. Who did it? If it always stays at -1 you don't know. If you run something and see it go to -3 you have your culprit. Only potential problem is the count could wrap to positive numbers after the 16384-th bogus double-close :-) (or is that 1,000,000,000 bogus double close ??:-) Either way, a real nice way to handle it. No gurus, you pay a little memory, which is a good tradeoff... ron
papa@pollux.usc.edu (Marco Papa) (09/14/88)
In article <368@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: |It is not a good idea to put this stuff in any of the libraries and |begin a precedent of tolerating software bugs. We must strive for |perfection in this operating system and associated applications or |we will eventually wind up limited by our own short sightedness. | |If we expect to continue to make progress we must be able to count on |certain activities in the os and applications. The ones that for some |reason or another fail to work properly must be revved to that other |applications and os software can count on well running execution |environment. All true, except that the current behavior (GURU on negative opencount) is simply unacceptable, especially since there are ways to avoid that. It makes ALL Amiga applications and the OS look flakey. Software bugs are "acceptable" in a "protected" machine. The Amiga is not such a machine. I perfectly agree that there should be some kind of warning message, which could be a Recoverable Dead Alert which could "name" the task that incorrectly decremented the library open count. Perfection is great. Unfortunately it doesn't sell machines per se. Error recovery seems much more important to me, especially in the OS of a non-protected multi-tasking machine, in which multi-vendor applications can stomp on each other. Since the protections are not in the hardware, the software HAS to do the extra job. Just my 5 cents. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mp1u+@andrew.cmu.edu (Michael Portuesi) (09/15/88)
> *Excerpts from ext.nn.comp.sys.amiga.tech: 13-Sep-88 Re: Negative Open* > *Counts (w.. root@sbcs.sunysb.edu (2237)* > In article <368@boing.UUCP>, dale@boing.UUCP (Dale Luck) writes: > > In article <39822@linus.UUCP> eachus@mitre-bedford.ARPA (Robert I. Eachus) > writes: > > > > It is not a good idea to put this stuff in any of the libraries and > > begin a precedent of tolerating software bugs. We must strive for > > perfection in this operating system and associated applications or > > we will eventually wind up limited by our own short sightedness. > > > No, relying on bug free programs for correct system operation > is just bad design. Bugs exist. > Bad press for the machine and silly if a few extra bytes spent doing > some minimal checking could have prevented it. I think what Dale was trying to say is that if developers encounter protection in some sections of the operating system, they will come to expect the same protection throughout and write programs based upon this (bogus) expectation. It's like walking across a bridge someone put between two cliffs for you, expecting the bridge to be solid along the way, but finding out it changes to a tightrope halfway through. More bad software could be written by programmers on the belief that all the software is robust than if they knew from the start they had to watch out for themselves. The logical extension of this argument is that the system software should either be as robust or as programmer-trusting as possible. I don't want to debate the merits of this proposition. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/15/88)
In article <1587@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: > No, relying on bug free programs for correct system operation > is just bad design. Bugs exist. The Amiga hardware and software both rely on bug free programs for correct system operation, and the only way to change that would be to replace the hardware and the software. It's not "bad design", it's just one of the many levels of protection that can be put in a system. There are other systems out there if this one is not up to your standards. > I would say that we > probably don't want to get into general argument checking, but simple, > fairly low rate of occurance calls can be checked: Open*/Close* > operations are always good candidates for checking. No matter how much we talk about this, it will not become possible with the current semantics of libraries. Many people taking part in this discussion don't seem to have realized yet that: (A) when an opencount goes negative, it is not possible to determine what program did more closes than opens, and (B) when this bug occurs, it is not possible to detect any anomaly in the opencount until AFTER the system has been subject to corruption for an unpredictable amount of time. Even if library usage were redesigned to be bullet-proof, what would be gained? There are bil-yuns and bil-yuns of ways to crash an Amiga. How many of them (and which ones) should be silently ignored when they are detected? As far as "public image" is concerned, is it better to say "Fatal error; system halted" or "System error; some or all of your data may be destroyed if you continue..."? I think the first answer will result in programs being fixed, and the second answer will result in a lot of people afraid to use the computer. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com
root@sbcs.sunysb.edu (root) (09/15/88)
In article <4736@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <1587@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: > The Amiga hardware and software both rely on bug free programs for > correct system operation, and the only way to change that would be > to replace the hardware and the software. It's not "bad design", > it's just one of the many levels of protection that can be put in > a system. There are other systems out there if this one is not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > up to your standards. ^^^^^^^^^^^^^^^^^^^^ (You actually work for Commodore? With your attitude I should hope not) The point here is that we need to do better on the Amiga. Perhaps it is not possible to do a 100% job here, but I am sure improvements can be made as we evolve to 1.4, 1.5, etc. > No matter how much we talk about this, it will not become possible with > the current semantics of libraries. Many people taking part in this > discussion don't seem to have realized yet that: (A) when an opencount > goes negative, it is not possible to determine what program did more > closes than opens, and (B) when this bug occurs, it is not possible to > detect any anomaly in the opencount until AFTER the system has been > subject to corruption for an unpredictable amount of time. Yes, of course we see this. But then the attitude that "if we can't do this 100% right we shouldn't do it at all" is silly. So yes we can construct pathological examples that break the open count management code. But then not all failure modes follow the example. My feeling on this (after watching the 20? messages fired off on the subject) is that a mix of Dale's and my original posting would provide satisfactory protection for now: pop a recoverable requester on opencnt < 0; mark library permanent. > Even if library usage were redesigned to be bullet-proof, what would > be gained? There are bil-yuns and bil-yuns of ways to crash an Amiga. > How many of them (and which ones) should be silently ignored when they > are detected? We would have chipped away at ONE of the ways to bomb the Amiga. We would have set a precedent that we will endeavor make the system more robust rather than taking a GURU. We will have started to think about tips and techniques to prevent GURU's, etc, etc. > > As far as "public image" is concerned, is it better to say > "Fatal error; system halted" > or > "System error; some or all of your data may be destroyed > if you continue..."? > > I think the first answer will result in programs being fixed, and the > second answer will result in a lot of people afraid to use the computer. Neither. It is better to design the system such that these things do not happen easily. > -=] Ford [=- > . . (In Real Life: Mike Ditto) > pardon our dust. ditto@cbmvax.commodore.com Rick Spanbauer Ameristar Technology
bilbo@pnet02.cts.com (Bill Daggett) (09/16/88)
My concern and 2 cents about GURUing, as an end user point of view and not
developer/programmer would be that instead of staring at a meaningless
flashing number on the screen, the machine could just go into a warm boot and
forget the guru message mouse clicking stuff. As a minimum otherwise, CBM
should at least publish what the GURU codes mean in Introduction to the
Commodore Amiga. Anyway, think about it CBM, and thanks for letting me share
this opinion with all of you.
Bill
UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!bilbo
INET: bilbo@pnet02.cts.com
* Sometimes The Dragon Wins! *peter@sugar.uu.net (Peter da Silva) (09/17/88)
In article <1596@sbcs.sunysb.edu>, root@sbcs.sunysb.edu (root) writes: > But then not all failure modes follow the example. I disagree. I think that most of the time, given the way the Amiga is set up, you would see this sort of failure mode. There are too many tasks popping in and out. Why don't you SetFunction(OpenLibrary) and implement one of your plans... and see what it does. > My feeling on this (after watching the 20? messages fired off on > the subject) is that a mix of Dale's and my original posting would > provide satisfactory protection for now: pop a recoverable > requester on opencnt < 0; mark library permanent. The only way to do this safely would be to track libraries on an ownership basis (per-task/per-library). This would require some code changes. > > "Fatal error; system halted" > > "System error; some or all of your data may be destroyed > > if you continue..."? Neither. I want it to say: Fatal error: Library closed twice. This error occurred in ieee.library. The responsible task was probably Ray-Trace-4d. Click left mouse button to reset. Click right button to kill Ray-Trace-4d. AT the very least, the GURU message should be replaced by something like this. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
billc@percival.UUCP (William Coldwell) (09/19/88)
In article <6988@gryphon.CTS.COM> bilbo@pnet02.cts.com (Bill Daggett) writes: >My concern and 2 cents about GURUing, as an end user point of view and not >developer/programmer would be that instead of staring at a meaningless >flashing number on the screen, the machine could just go into a warm boot and [stuff deleted] > >Bill > >UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!bilbo Actually, how about when the Amiga barfs, to tell which task is barfing, and allow the user to terminate the task and flush the resources and libraries (pending a fix to the -# usecount)? I think that this would be more of a visual help to the user rather than shutting the whole system down. GOMF seems to do a pretty decent job of remeding the situation... how about a real fix? I mean, hell if the operating system is going to be revamped, why not handle a stray task a little bit better? Bill -- William J. Coldwell Creative Microsystems "We the unwilling, Amiga Attitude Adjuster 10110 SW Nimbus B1 led by the unknowning, (Software Developer) Portland, OR 97223 are doing the impossible, "Blame the hardware" (503) 684-9300 for the ungrateful..."
billc@percival.UUCP (William Coldwell) (09/19/88)
In article <2643@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <1596@sbcs.sunysb.edu>, root@sbcs.sunysb.edu (root) writes: >> But then not all failure modes follow the example. > >I disagree. I think that most of the time, given the way the Amiga is set up, >you would see this sort of failure mode. There are too many tasks popping >in and out. Why don't you SetFunction(OpenLibrary) and implement one of >your plans... and see what it does. > >> provide satisfactory protection for now: pop a recoverable >> requester on opencnt < 0; mark library permanent. > [misc stuff deleted for sake of sanity...] >Neither. I want it to say: > > Fatal error: Library closed twice. > This error occurred in ieee.library. > The responsible task was probably Ray-Trace-4d. > Click left mouse button to reset. > Click right button to kill Ray-Trace-4d. GREAT! This is the idea here. Kill the task, not the machine! >-- > Peter da Silva `-_-' peter@sugar.uu.net Now, if we go back to when I asked WHY this was happening, I was told that it was a bug with Manx not doing CloseLibrary() correctly (actually it's just doing it very well twice). This is due to a compiler problem, not a hardware problem, nor really a system software problem. So, it seems that the OS must be changed to prevent this from every happening again, right? Well, if the compiler problem was corrected, then future problems would be resolved (for the most part, we can't change the OS to prevent programmer errors - though it would be quite nice ;-) ) - right? As for the current people out there still compiling under the bugged compiler should just simply recompile and redistribute the corrected version. I would hate to have an 8M OS, and only 1M to play in ;-)! Bill -- William J. Coldwell Creative Microsystems "We the unwilling, Amiga Attitude Adjuster 10110 SW Nimbus B1 led by the unknowning, (Software Developer) Portland, OR 97223 are doing the impossible, "Blame the hardware" (503) 684-9300 for the ungrateful..."
kevin@amdahl.uts.amdahl.com (Kevin Clague) (09/19/88)
In article <1370@percival.UUCP> billc@percival.UUCP (William Coldwell) writes: > > Now, if we go back to when I asked WHY this was happening, I was told > that it was a bug with Manx not doing CloseLibrary() correctly (actually > it's just doing it very well twice). This is due to a compiler problem, I think the bug has to to with Manx's glue code for IEEE. When you compile for IEEE operands all the IEEE access routines eventually go to one place, and check to see if the global variable that holds the IEEE library base is NULL. If not they try to open the library. if this fails, the machine crashes. This is the bug, not Manx closing libraries too many times. A bug in Manx's IEEE glue routines makes Dale go off and change his IEEE CloseLibrary() stuff? Something smells fishy. Like Manx'es or my code. Not the IEEE library. William is right. Fix my code, and Manxes code. Not the innocent bystander code. I'm not against the library opens being tracked on a per task basis, but I think that resource tracking should be addressed for everything not just IEEE libraries. I'd much rather see Commodore solve this problem rather than talking about how to fix a Manx bug in the IEEE libraries. 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. ]
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/20/88)
>In article <4736@cbmvax.UUCP>, I wrote: [ that every system has *some* limits, even the Amiga. Other systems might have different kinds of limitations ] ... except I said it in a perhaps not-so-nice way, which resulted in: In article <1596@sbcs.sunysb.edu> root@sbcs.sunysb.edu (root) writes: > (You actually work for Commodore? With your attitude I should hope not) Remember, attitudes and opinions are not related to those of employers! :-) My point was that *any* system has some limitations. Some of the Amiga's limitations can not go away in a compatible way. I don't think there is anything wrong with the design of the Amiga system as long as *at least* the software developers know the limitations; the users can (and should) be kept unaware of internal details of implementation. Among the critical things that any developer must know are things which can crash the system. As long as we have the current system of Amiga hardware and software, there must exist the rule "programs must never do something which can crash the system." Eliminating one (or ten, or a hundred) ways to crash the system will not allow us to remove that rule. > We would have chipped away at ONE of the ways to bomb the Amiga. We > would have set a precedent that we will endeavor make the system more > robust rather than taking a GURU. We will have started to think > about tips and techniques to prevent GURU's, etc, etc. I heartily recommend allowing the system to recover from errors. But that is not what was proposed; it was to have the system continue running without warning when a non-recoverable condition had been detected. In this particular example, it would usually allow the system to operate normally. The end result, however, would be rare, but catastrophic, system failures without any evidence of cause. I think that will bother Pournelloids at least as much as the "Software Error" messages they replace. I agree that users should be isolated from system internals and that the system should be as programmer-forgiving as possible. I don't think it should do this at the expense of reliability or critical-error reporting. [ ... ] > Neither. It is better to design the system such that these things > do not happen easily. All right, but let's talk about *design* then, not "recovery". Yes, many of these problems could be eliminated by a new library system design, but I don't think that's necessary. There is just a "philosophy" of Amiga programming which must be kept in mind; it is fairly consistent across all the parts of the Amiga system, and it works just fine within the scope it was intended to work in. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com These comments have been the personal opinions of Me, Myself, and I, and are not related to Commodore-Amiga official policy.
cc1@valhalla.cs.ucla.edu (Michael Gersten) (09/22/88)
In article <2643@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >Neither. I want it to say: > > Fatal error: Library closed twice. > This error occurred in ieee.library. > The responsible task was probably Ray-Trace-4d. > Click left mouse button to reset. > Click right button to kill Ray-Trace-4d. I have a better idea: Warning: Library closed twice. This error occurred in ieee.library. The program running when detected was Ray-Trace-4d. Click left mouse button to reset. Click middle button to kill Ray-Trace-4d. Click right button to continue Note: **NEVER, never FORCE a reboot when disk activity may be going on. Note 2: Always allow the person to recover Note 3: If you can't figure out who did it, don't require a kill Note 4: You do have a 3 button mouse, don't you? :-)
aleks@well.UUCP (Brian J. Witt) (09/25/88)
[The line eater is dead-- the line eater is dead!!!]
It seems that if you're going to open the math library and your runtime
_may_ also open the math library, that you should keep track of your open
seperate from the runtime library. Carloyn Schneppner (I hope I spelled
that correctly) has outlined how to do this. Its like this, for sure!
This uses the re-enterency technique. You may have many openers in
your process all sharing one global variable. The routine that first
opened the library should be the routine that is responsible for closing
the library. And once closed, it should modify that single global var
sothat should any one else need it later, they can deal with that
situation.
main ()
{
struct Library *myMathBase = NULL;
if (runtimeMathBase == NULL) {
if ((myMathBase=OpenLibrary(..)) == NULL)
error ("!");
runtimeMathBase = myMathBase;
}
/* Insert useful code .. */
/* Cleanup and go home: */
if (myMathBase != NULL)
{
CloseLibrary(runtimeMathBase);
runtimeMathBase = NULL; /* WE closed it */
}
} /* main */
This should work out well, no matter who needs the library.
1) The startupcode has already opened the library. Great, you don't
close it. The runtime rundown code will close its own library.
2) The startup has not opened the library. Ok, you do it for the
system and assign it to the system library base. Since you
did the open, at cleanup time you close the library and set the
varaible to NULL. The runtime rundown code sees the var NULL and
should ignore it.
I needed this solution when using IconBase under Manx. It seems its
already declared in wb_startup(). In my program it's delcared 'extern'
and since I didn't really trust anyone to tell me if it was opened or
not, I did it this way.
Hope it helps!
brian
---------------------------------------------------------------------
"Some days, doctor, I wake up and I don't even know who I am.."
-- confessions of an abstraact data type
---------------------------------------------------------------------dale@boing.UUCP (Dale Luck) (09/26/88)
In article <7193@well.UUCP> aleks@well.UUCP (Brian J. Witt) writes: >[The line eater is dead-- the line eater is dead!!!] > >It seems that if you're going to open the math library and your runtime >_may_ also open the math library, that you should keep track of your open >seperate from the runtime library. Balony, the runtime library should be keeping out of the way of the main program. Fact is: this particular runtime library has a bug in it. Let's not start writing code assuming the support system has faults, let's get those faults corrected as the source instead of bandaids in user code. Each system should be responsible for releasing the resources it allocated. If the user code always opens the ieee library, then the user code can just always close that same library. If the runtime library was using the global variable MathBase mistakenly as a flag to see if the library was opened then get the runtime library fixed to either always open/close the library or, use private flag to tell the RUNTIME library that it needs to close a library that IT opened. -- 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.