--- a/WeakArr.st	Fri Oct 28 02:30:26 1994 +0100
+++ b/WeakArr.st	Fri Oct 28 02:30:48 1994 +0100
@@ -1,6 +1,6 @@
 "
  COPYRIGHT (c) 1991 by Claus Gittinger
-              All Rights Reserved
+	      All Rights Reserved
 
  This software is furnished under a license and may be used
  only in accordance with the terms of that license and with the
@@ -19,9 +19,9 @@
 
 WeakArray comment:'
 COPYRIGHT (c) 1991 by Claus Gittinger
-              All Rights Reserved
+	      All Rights Reserved
 
-$Header: /cvs/stx/stx/libbasic/Attic/WeakArr.st,v 1.6 1994-10-10 00:29:09 claus Exp $
+$Header: /cvs/stx/stx/libbasic/Attic/WeakArr.st,v 1.7 1994-10-28 01:30:48 claus Exp $
 '!
 
 !WeakArray class methodsFor:'documentation'!
@@ -29,7 +29,7 @@
 copyright
 "
  COPYRIGHT (c) 1991 by Claus Gittinger
-              All Rights Reserved
+	      All Rights Reserved
 
  This software is furnished under a license and may be used
  only in accordance with the terms of that license and with the
@@ -42,7 +42,7 @@
 
 version
 "
-$Header: /cvs/stx/stx/libbasic/Attic/WeakArr.st,v 1.6 1994-10-10 00:29:09 claus Exp $
+$Header: /cvs/stx/stx/libbasic/Attic/WeakArr.st,v 1.7 1994-10-28 01:30:48 claus Exp $
 "
 !
 
@@ -66,12 +66,23 @@
     (for example, the ResourcePack class uses a WeakArray to cache recently
     used resource data for a while).
 
+    The way in which weakArrays get informed by the runtime system is via
+    an interrupt (DisposeInterrupt). The reason for not sending messages
+    directly from the VM is to make it possible, to run the finalization
+    code at lower priority or from another class. 
+    Also, as a side effect, it is possible to delay finalization by blocking 
+    interrupts
+
     This interrupt is cought here and informs the watcher and, if there is
     a dependent, this one gets informed as well (I dont know, which of the
     two mechanisms will survive in the long run - I started with the watcher,
     but now switch to dependencies since they seem to provide more flexibility).
     Therefore, be prepared, that the watcher mechanism will vanish in the 
     future.
+
+    NOTICE: weakArray handling add some (small) overhead to the VM (each weakarray
+    is scanner after each GC). It is uncertain, if the current mechanism works well
+    with (say) thousands of weakArrays.
 "
 ! !
 
@@ -81,11 +92,11 @@
     "setup the private signal"
 
     RegistrationFailedSignal isNil ifTrue:[
-        Object initialize.
+	Object initialize.
 
-        RegistrationFailedSignal := Object errorSignal newSignalMayProceed:true.
-        RegistrationFailedSignal nameClass:self message:#registrationFailedSignal.
-        RegistrationFailedSignal notifierString:'weakArray registration failed'.
+	RegistrationFailedSignal := Object errorSignal newSignalMayProceed:true.
+	RegistrationFailedSignal nameClass:self message:#registrationFailedSignal.
+	RegistrationFailedSignal notifierString:'weakArray registration failed'.
     ]
 ! !
 
@@ -120,38 +131,38 @@
 
     ok = __addShadowObject(self, 0);
     if (ok == false) {
-        /* 
-         * this happens when too many shadow objects are
-         * already there, collect garbage to get rid of
-         * obsolete ones, and try again.
-         * since a full collect is expensive, we try
-         * a scavenge first, doing a full collect only if 
-         * that does not help.
-         */
-        nonTenuringScavenge(__context);
-        ok = __addShadowObject(self, 0);
-        if (ok == false) {
-            /* try more ... */
-            scavenge(__context);
-            ok = __addShadowObject(self, 0);
-            if (ok == false) {
-                /* hard stuff - need full collect */
-                __garbageCollect(__context);
-                ok = __addShadowObject(self, 0);
-                if (ok == false) {
-                    /* mhmh - it seems that there are really many shadow 
-                       objects around - force creation */
-                    ok = __addShadowObject(self, 1);
-                    if (ok == false) {
-                        /* no chance - something must be wrong */
-                    }
-                }
-            }
-        }
+	/* 
+	 * this happens when too many shadow objects are
+	 * already there, collect garbage to get rid of
+	 * obsolete ones, and try again.
+	 * since a full collect is expensive, we try
+	 * a scavenge first, doing a full collect only if 
+	 * that does not help.
+	 */
+	nonTenuringScavenge(__context);
+	ok = __addShadowObject(self, 0);
+	if (ok == false) {
+	    /* try more ... */
+	    scavenge(__context);
+	    ok = __addShadowObject(self, 0);
+	    if (ok == false) {
+		/* hard stuff - need full collect */
+		__garbageCollect(__context);
+		ok = __addShadowObject(self, 0);
+		if (ok == false) {
+		    /* mhmh - it seems that there are really many shadow 
+		       objects around - force creation */
+		    ok = __addShadowObject(self, 1);
+		    if (ok == false) {
+			/* no chance - something must be wrong */
+		    }
+		}
+	    }
+	}
     }
 %}.
     ok ifFalse:[
-        ^ RegistrationFailedSignal raiseRequestWith:self
+	^ RegistrationFailedSignal raiseRequestWith:self
     ]
 ! !
 
@@ -177,10 +188,10 @@
      whenever any shadowArray looses a pointer."
 
     self allChangedShadowObjectsDo:[:aShadowArray | 
-        aShadowArray changed.
-        aShadowArray watcher notNil ifTrue:[
-            aShadowArray watcher informDispose
-        ]
+	aShadowArray changed.
+	aShadowArray watcher notNil ifTrue:[
+	    aShadowArray watcher informDispose
+	]
     ]
 ! !