2010/10/11 Levente Uzonyi <leves at elte.hu>:
> On Mon, 11 Oct 2010, Igor Stasenko wrote:
>
>> On 11 October 2010 17:24, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote:
>>>
>>>> Levente,
>>>>
>>>> A similar discussion arose around Dolphin's event (#trigger*) mechanism.
>>>>  My recollection is that it was not fully addressed due to performance
>>>> concerns.  Forking and error handlers both have their costs.  I'm not
>>>> saying
>>>> we should necessarily follow (we probably should not), though with
>>>> careful
>>>> design, an interrupted chain of events might survive to be handled on a
>>>> subsequent attempt.
>>>>
>>>> I am far more worried about having multiple executors per object (when
>>>> did
>>>> p=malloc();free(p);free(p);free(p) become good style?) than I am about
>>>> getting the finalizer process itself completely robust at this point.
>>>
>>> Smalltalk is not C. Try this:
>>>
>>> | file |
>>> file := StandardFileStream fileNamed: 'foo.txt'.
>>> file close.
>>> file primClose: (file instVarNamed: #fileID).
>>> "Those pesky plugins save us all the time. ;)"
>>>
>>>
>>
>> Don't let me starting again on this.
>> You proposing to care about it in multiple various places, where we
>> could fix it in a single one.
>> It is like adding ifNotNil: test at each place you using setter,
>> instead of putting a single ifNotNil: test inside a setter itself.
>>
>>
>> try this:
>>
>> coll := OrderedCollection new.
>> obj := Object new.
>> wrapper := WeakArray with: obj.
>> coll add: wrapper.
>>
>> obj toFinalizeSend: #remove: to: coll with: wrapper.
>> obj toFinalizeSend: #remove: to: coll with: wrapper.
>> obj toFinalizeSend: #remove: to: coll with: wrapper.
>> obj toFinalizeSend: #remove: to: coll with: wrapper.
>>
>> obj := nil.
>> Smalltalk garbageCollect.
>>
>>
>> The above works silently only because ObjectFinalizer simply swallows
>> any errors:
>>
>> ObjectFinalizer>>finalize
>>        "Finalize the resource associated with the receiver. This message
>> should only be sent during the finalization process. There is NO
>> garantuee that the resource associated with the receiver hasn't been
>> free'd before so take care that you don't run into trouble - this all
>> may happen with interrupt priority."
>>        [self value] on: Error do:[:ex| ex return].
>>
>> now, replace this implementation with just
>> self value
>> and you'll see what will happen.
>>
>> Such behavior is completely unacceptable in terms of finding the bugs
>> & problems in your code.
>>
>
> Argh. Your mail client splitted this thread too.

To all:
my apologies.
Lets continue this thread in squeak-dev only. (choice is not based on
any personal/political preference ;) )

> Interrupting the finalization process is also a bad idea, so we need a
> better solution.
>

Yes. That's why i started this thread.
I'm not looking for immediate & perfect solution, but my current
intent is to let everyone know that there are issues
which we need to take care of.

I was also trying to poll people's reaction on it. Because from first
glance it may look as a minor issue.
However, for production-ready & stable environments, this issue could
become a critical one.

>
> Levente
>


-- 
Best regards,
Igor Stasenko AKA sig.