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.
Interrupting the finalization process is also a bad idea, so we need a 
better solution.


Levente

>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>