2009/5/3 John M McIntosh <[email protected]>:
> 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?
>

Yes!
RemoteString patch is what I would call "un pansement sur une jambe de
bois" unless it has more of "un arbre qui cache la forêt"..
We need to write a SUnit TestCase stressing the finalization mechanism
and identify what's going on.
Debugging such low level high priority multi-process may imply
instrumenting the VM though...

Nicolas

> 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

Reply via email to