>John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
>>  Ya, for your interests what I'm doing is starting a Swiki, then bring
>>  up a page, then hold the refresh page command key down, this works
>>  best from Netscape Unix since  it queues the keystrokes. This
>>  generates 100's of HTTP connections. Some of which timeout and the
>>  browser closes the socket in the middle of connection. Do this for a
>>  few minutes, observe 100's of Sockets waiting to be finalized. Do a
>>  full GC or wait awhile. Examine macintosh Squeak TCP/IP structures,
>>  see a couple of sockets in error state, but also *NOT* processed by
>>  destroy. Wonder why no instances of sockets in image, but 8 socket
>>  handles still allocated, they won't be destroyed now since the image
>>  does't have a reference to them anymore. Quit Squeak, paranoid
>>  cleanup logic hunts down and closes the 8 sockets.
>>
>
>
>Wonderful test!  FWIW, I tried it with Squeak 2.8alpha (slightly old)
>and Com45Swiki9 on Linux.  I did get quite a large number of debugger
>windows and a few hundred open sockets, but:
>
>	1. The final request to the server did succeed.
>
>	2. After closing all the debuggers and doing a "space left", all the
>open sockets went away.


Ok, I'm not sure why you get the debugging windows? Must be in Com45Swiki9?

What you might want to try is to create your own subclass of 
WeakRegistry, then use that to replace the one that the Socket class 
allocates. Now count the number of add: that are done, and count the 
number of removes that are done, in I think remove:ifAbsent: and in 
finalizeValues (Of course check to see if I didn't miss one) I 
*think* when you do Socket closeAndDestroy or destroy or finalize a 
socket then we should have equal counts. However right now it tells 
me that 31 sockets were added to the dictionary, but only 25 requests 
for socket removal, but the valueDictionary only contains the listen 
socket, where did the other 6 go?

Sooo I've been thinking what if adding them to the dictionary runs 
into a duplication problem? Well doing a little looking shows me we 
first lookup the hash of the object to get the location in the 
WeakKeyDictionary to probe. This uses hash which in Socket isn't 
defined so it uses Object>>hash, which is self identityHash, which 
calls primitive 75. Primitive 75 is primitiveAsOops which returns a 
12bit value... This jives with what John Maloney told me earlier this 
year that Squeak returns a identity hash value in a rather small 
range, so you CAN have objects that have the same identityHash.

The code in Dictionary>>scanFor: then hunts from that location, and 
wraps if required! It uses '=' to see if it can find a match. 
Object>>= does ^self == anObject and ProtoObject>>== does primitive 
110 which is primitiveEquivalent which in the C code takes the first 
32bits from each object and compares. I'm assuming this is an 
address. Thus this logic appears ok (unless I missed something). I 
didn't consider looking too hard at it today, until Lex's note 
because I'm assuming it should be fine, because lots of stuff would 
break if there was some sort of problem adding items to a Dictionary. 
Then again it's an WeakKeyDictionary and overrides at:put: (sigh more 
thought).

Oh well at least it's an *interesting* problem. Right now I'm 
thinking about Set>>fixCollisionsFrom: index and mmmm what if the key 
is nil that follows the one we deleted, but doesn't the 
WeakKeyDictionary keys go to nil... I seem to recall that VisualWorks 
drops a 0 in as the key when it alters the WeakArray, perhaps 
something interesting is happening during removal I think I'll go 
over and examine ObjectMemory>>finalizeReference: and consider the 
implications of keys going to nil when fixCollisionsFrom: is running.


PS I did add a counter to Socket to look at Socket allocations, this 
jives with the number of Sockets added to the WeakRegistery.

>
>Closing the debuggers alone did *not* do the trick, so it looks like
>GC+finalization did close a lot of those sockets.  (Also, it's too bad
>this scenario brings up debuggers, but that's a separate problem).
-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================