Path: utzoo!attcan!uunet!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IEEE libraries
Summary: Guru is better than silent ignorance.
Keywords: IEEE library opencount
Message-ID: <4724@cbmvax.UUCP>
Date: 13 Sep 88 23:27:13 GMT
References: <1356@percival.UUCP> <b03Kac9bnd10108qAIk@amdahl.uts.amdahl.com> <358@boing.UUCP> <1570@sbcs.sunysb.edu>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 63

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