If you're not on the Squeak list, you may not know about the current very active thread of people working on the last of the Mac server bugs -- the mysterious uncollected sockets (see below). Wonderful news! Mark >Resent-Date: 12 Oct 2000 05:24:35 -0000 >Resent-Cc: recipient list not shown: ; >X-Sender: [EMAIL PROTECTED] >Date: Wed, 11 Oct 2000 22:25:14 -0700 >To: [EMAIL PROTECTED] >From: John M McIntosh <[EMAIL PROTECTED]> >Subject: RE: 3 new mac VMs + pending Mac VM... >Resent-From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/25550 >X-Loop: [EMAIL PROTECTED] >Resent-Sender: [EMAIL PROTECTED] > >>John, >> >>>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... >> >>Just to complete your confusion: Be advised that fixCollisionsFrom: is >>mainly based on the *associations* in a dictionary and that only the keys of >>those associations will be niled out. Thus, rehashing isn't even absolutely >>necessary (I think) but it seemed a lot safer to me when I wrote it. >> >>Considering Lex' observations on Linux I'd rather check the support code >>than the image side. Is it eventually possible that at some point >>primitiveSocketDestroy will fail on a socket?! The assumption is that unless >>this socket is really invalid primitiveSocketDestroy will destroy it under >>all circumstances. Maybe you could add a bit of code that prints out an >>error message if it fails to destroy a socket and continue from there. > >Well I've looked at that. The Mac VM sqSocketDestroy attempts to >close/zap what ever the socket, and regardless of the socket state >it sets the socket handle to nil, and decrements a counter, which I >incremented at socket creation. If I drop into the debugger I can >see the counter is too high and doesn't match the number of Sockets >that Squeak has allocated in the image. Thus my concern that destroy >is never called! > >This also jives with my examinations of WeakRegistry were I don't >think the right number of removals occur to match the additions. At >some point additions to the WeakRegistry become greater than >removals after all finalization has occurred. > >If for example in WeakRegistry>>finalizeValues where we are creating >that finObjects collection, then we invoke finalizeValues on the >WeakKeyDictionary, what protection do we have from the VM from >nilling keys as part of a GC between the traversal of the >WeakKeyDictionary hunting for nils, then part (B) destroying the >nils as this seems tobe a two step process? > >> >>BTW, I have had this problem before on Windows - with a threading mechanism >>you may have a socket which is temporarily in a weird state and which need >>to stabilize before it can be destroyed. As an example, if your socket is in >>a blocking wait/read/write you may have to wait for completion of the >>operation before the socket can actually be closed. Also, if you don't wait >>you may loose OS resources (the way I did this first did leave some open >>resources on Windows and it took me some time to understand the issue). What >>I am doing these days is basically to signal that this socket should be >>destroyed when it comes back into a stable state and leave the actual >>cleanup to the last thread releasing the socket. > > >Yes I first ask the socket to go away, then I ask it rudely, then I >get hostile and drop it on a queue for disposal at a later time. The >disposal logic runs as part of socket creation, and is very very >good at fixing up or tossing busted sockets, no the current mac vm >does NOT have any lurking threads (I've been tempted, but not today). > >> >>Anyways, I'd strongly recommend to look at the support code. Trace those >>primDestroy things and if you defer close/destroy operations trace if they >>are *always* executed. It's quite possible that the right number of >>#primDestroys is sent to your primitive code and something just doesn't >>close 'em. >> >> - Andreas >> >>PS. *If* the problem is in the support code it might also explain some of >>the sudden slowdowns we've heard of. I remember this problem from Windows >>where a high-priority socket process run wild and zapped all CPU time... > > >I think this is a side effect of the problem. If we don't destroy >the sockets and they get into the right state (this-side-closed with >pending read) then I run low on support code buffers. This state is >handled, but there is a bug which is exposed for which I'm going to >issue a fix real soon now. This *could* be related to your slowdown. >What happens is for example your background task doing reading on a >socket will loop attempting to read pending data, but the data can't >be read because of a unique error, and bug, we just report we can't >read the data right now try again. Of course your code does try >again, forever, really fast which slows things down. > > > >-- >-- >=========================================================================== >John M. McIntosh <[EMAIL PROTECTED]> 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 >=========================================================================== -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : [EMAIL PROTECTED] http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
