[Pharo-project] Another finalization concern: error handling

Schwab,Wilhelm K bschwab at anest.ufl.edu
Mon Oct 11 10:34:38 EDT 2010


Levente,

Ok, but just because the system saves us at the last instant does not mean that we should be going out of our way to multiply free external resources.  Files are well known to the vm; other things (GSL vectors/matrices comes to mind) will not enjoy such protections.  This strikes me as a feature that got added when errors arose from attempts to add redundant executors, ultimately due to lack of thread safety.  Many things that are being fixed at great cost got started (it sure seems) because someone added a feature or placed something in or too near to Object only to avoid errors vs. finding and fixing the real problem.

Maybe you have made a strong argument for multiple executors; if so, I've missed it.  Right now, it looks like a design flaw instead of a feature.

Bill



________________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves at elte.hu]
Sent: Monday, October 11, 2010 10:24 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Another finalization concern: error handling

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. ;)"


Levente

>
> Bill
>
>
>
> ________________________________________
> From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves at elte.hu]
> Sent: Monday, October 11, 2010 9:51 AM
> To: Pharo Development
> Cc: The general-purpose Squeak developers list
> Subject: Re: [Pharo-project] Another finalization concern: error handling
>
> On Mon, 11 Oct 2010, Igor Stasenko wrote:
>
>> Hello,
>>
>> here a situation, with which we can deal in more safer manner:
>>
>> Suppose you have a weak registry, populated by different objects and
>> their executors.
>>
>> Now, when some of them died, a weak registry performs finalization.
>>
>> The potential danger is , that if there's an error triggered by some
>> executor(s),
>> then rest of executors will have no chance to run and will be
>> forgotten, causing memory leakage.
>>
>> What you think, should we handle this more graciously?
>>
>> (Consider a following meta-code)
>>
>> WeakRegistry>>finalizeValues
>> | executors |
>>  executors := self gatherExecutorsToRun.
>>
>>  executors do: [:ex |
>>     [ ex finalize ] fork.
>>  ].
>
> The "gatherExecutorsToRun" part was implemented in the previous version
> of WeakRegistry (history is not available from the image...). #finalize
> wasn't sent from the protected block. The current version lacks it, so it
> will deadlock if a finalizer will try to access the same WeakRegistry.
> Other kind of deadlocks are also possible. For example when a finalizer
> can access a semaphore which is also used by another process that
> uses the same semaphore and also uses the WeakRegistry, but locks them in
> a different order (JNIPort).
> This only happens if the VM doesn't support the new finalization scheme
> which is the case for most current VMs.
>
> There is another issue with removal, and this affects the new finalization
> scheme too, because the finalizer of valuesDictionary is #finalizeValues.
> This means that finalization can happen in a process other than the
> finalization process. This can lead to random errors.
>
> So I think parts of the old WeakRegistry implementation should be
> restored, like:
> - WeakRegistry should collect executors
> - executors should be evaluated outside the protected block
>
>>
>> in this way, if any executor's #finalize causing error, it won't
>> interfere with other executors, and they will accomplish their task
>> normally.
>> Of course, i'm not saying that we should use #fork for this, because
>> it is costly. Similar could be done w/o forking.
>> I just wanted to show a simplest code with which we could achieve a
>> more gracious error handling.
>
> Wouldn't it be better to use an exception handler?
>
>
> Levente
>
>>
>> P.S. of course, in a first place it would be good to make sure that we
>> writing executors, which can't cause an error during finalization.
>> But bad things happen, and we should make sure that rest of system
>> won't be put on its knees because of some stupid bug in a single
>> #finalize.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Pharo-dev mailing list