On Mon, 11 Oct 2010, Igor Stasenko wrote:
On 11 October 2010 17:24, Levente Uzonyi <leves@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. Interrupting the finalization process is also a bad idea, so we need a better solution. Levente -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project