🚀 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:
| > >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)