>
>
>
>These tests show that if there are errors in the general GC+finalization
>mechanism, they are subtle ones.
>
>	-Lex


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.

Of course the original issue was why does a Swiki locking up under 
load/ or after a long period of time.

Sigh...

Your point of dumping to a file is a good one, I'll set that up later 
today to track socket allocation and destruction. I did this in the 
image, but then the problem disappeared! So... need to get away from 
the garbage collector to prove it's the garbage collector, or 
something else.
-- 
--
===========================================================================
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
===========================================================================