Monticello/ftp stopped working for me

> 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.

>
>
> 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 <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 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 <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/5/3 John M McIntosh <[hidden email]>:
>> 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.
>>
> IMO this should be done sooner or later. Its a pain to see it.
> Oh well, too bad, this is not the only thing which requires  
> attention :)
>
>> (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.
>>
> I used finalization in my code multiple times. It didn't caused many
> problems, if you know how to do it right (by taking an implementation
> into account).
>
>> 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.
>>
> It looks like i missed this part. Where i can read details about what
> is altered in finalization, which could break things?

>
>
>> 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, i proposed a little change to VM (just a couple lines of code in
> single method + registering additional special object)
> which would allow us more direct finalization.
> It not makes weak refs to be a full pledged ephemerons, but much
> easier to adopt in VM. And besides you wont find any finalization code
> in squeak which relies on ephemeron's special behavior -- reference
> 'value' slot weakly, only when reference in 'key' slot is dies.
>
> http://www.nabble.com/An-idea-about-better-finalization-support-td23186805.html
>
>
>> On 2-May-09, at 1:52 PM, Stéphane Ducasse wrote:
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>