On May 3, 2009, at 1:46 AM, John M McIntosh wrote: > 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.
Yes this was also implied in my remark. > 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. I agree! > > > 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 > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
