Beware: there are two issues here, not one. (a) the faulty remoteString code is ill behaved. Fine that can be fixed or as Igor suggested refactored to oblivion.
(b) The deeper issue is that we affected how finalization works so that this ill behavior now causes application failure. If in the past it worked, now it doesn't I don't see anyone really having a good answer other than perhaps my guess, and how do we get back to the point were ill behaviour by *my* code won't cause Socket Failures. No doubt people have ugly code that is *silently* busted like RemoteString, but they don't know it. And as you saw actually finding the culprit is difficult. Lastly some people DO use finalization to do resource cleanup on purpose, not as a safety fallback, so they will be impacted I think by the new Pharo behaviour. Wasn't finalization tagged as bloated and need fixing? Igor I'm sure suggested a few things before the flurry of code for optimizing semaphores and process switching? On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote: > Yes but why don't we close them with an ensure or something like that. > I mean is the logic of the connection making it that we cannot use > ensure or this is just a legacy? > > On Apr 30, 2009, at 7:20 PM, John M McIntosh wrote: > >> Well somewhere someone needs to close the socket before it is >> *forgotten* >> >> On 30-Apr-09, at 5:29 AM, Stéphane Ducasse wrote: >> >>> I would like to know why does the system rely on finalisation to >>> release socket >>> Apparently david mentioned that this is the source of huge problems. >>> So what would be the alternative? >>> >>> Stef >> -- = = = ======================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
