🚀 go-pugleaf

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