[squeak-dev] Re: [Pharo-project] Another finalization concern: error handling

Eliot Miranda eliot.miranda at gmail.com
Mon Oct 11 22:56:29 UTC 2010


On Mon, Oct 11, 2010 at 3:07 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 12 October 2010 00:02, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Igor,
> >     take a look at the VisualWorks finalization code.  There a process is
> > spawned to run each finalizer, and there is a throttling mechanism to
> ensure
> > that the system does not create a flood of processes when lots of objects
> > are to be finalized.  Instead, a new finalization process is created only
> > when the previous one starts to run.  A new finalizer process is created
> > when the previous one starts because, due to errors, the previous one may
> > never finish, but it will always start.
>
> This is a little bit confusing. Did you mean:
>
> new finalization process is created only when the previous one _stops_ to
> run
>

No.  The top-level loop spawns processes at a lower priority to run
finalization; I'll call these sub-processes.  If one creates a sub-process
as soon as an object is available to finalize then the system can end up
creating many many sub-processes, none of which can run since the top-level
process is busy creating sub-processes.  If one creates a sub-process only
when a previous sub-process terminates then the system is no different to
now; if an error occurs in a sub-process taht prevents it teminating then no
more sub-processes are created and finalization stops.

If instead one creates a new sub-process when a previous sub-process starts
executing (starts executing is not the same point in time as create the
process) then there are only ever two subprocesses, the one already running,
and the one that was created when the first started running, but has not
started running since cooperative scheduling means it is queued behind the
previous sub-proecss.  However, as soon as an error occurs in the previous
sub-process, the one that was created when the sub-process with the error
started will start running and create another one.

Read the VisualWorks source code and it will, I hope, become clear.


> and
>
> A new finalizer process is created when the previous one _stops_
> because, due to errors
>

No.  See above.  When the sub-process *starts*.

best
Eliot


> ?
>
> > outerFinalizationLoop
> > "Forks a process that will send every finalizable object (weak
> > indexable class or Ephemeron) on the finalization  queue the
> > mourn message. Separate processes are used to fetch
> > finalizable objects and to finalize them so that if errors occur
> > in finalization they don't stop the finalization mechanism
> > altogether.  This method uses the ratchet semaphore to arrange
> > that each new processes is only forked after the previous
> > process has made progess.  Hence this avoids creating many
> > new processes that can't run because they have lower priority
> > than the finalization process, and in the process possibly
> > running out of memory."
> > | theBereaved ratchet |
> > ratchet := Semaphore new.
> > [FinalizationSemaphore wait.
> > theBereaved := [self fetchFromFinalizationQueue]
> > on: self queueOverflowSignal
> > do: [:ex | ex return: #overflow].
> > theBereaved == nil ifFalse:
> > [[ratchet signal.
> >  self innerFinalizationLoopWith: theBereaved]
> > forkAt: Processor lowIOPriority.
> > ratchet wait]] repeat
> > innerFinalizationLoopWith: initialValue
> > "Sends every finalizable object (weak indexable class or Ephemeron) on
> the
> > finalization queue the mourn message."
> > initialValue == #overflow ifTrue:
> > [^self handleFinalizationQueueOverflow].
> > [| theBereaved |
> > theBereaved := initialValue.
> > [theBereaved mourn.
> >  (theBereaved := self fetchFromFinalizationQueue) ~~ nil] whileTrue]
> > on: self queueOverflowSignal
> > do: [:ex |
> > self handleFinalizationQueueOverflow.
> > ex return]
> >
> > (there are details like the use of handleFinalizationQueueOverflow that
> you
> > can ignore)
> > HTH
> > Eliot
> > On Mon, Oct 11, 2010 at 1:17 PM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab at anest.ufl.edu>
> wrote:
> >> > Sig,
> >> >
> >> > The most important words in there are "critical section."  Carry on :)
> >> >
> >>
> >> Oh, please. This is not too hard to code.
> >>
> >> My mind rolling around following choice(s)  (there may be others i don't
> >> see).
> >> What would be a proper way to handle error during #finalize.
> >>
> >> [ executor finalize ] on: Error do: [:ex |
> >>  self handleFinalizationError: ex  "where self is registry"
> >>  ].
> >>
> >> or:
> >>
> >> [ executor finalize ] on: Error do: [:ex |
> >>  executor handleFinalizationError: ex
> >>  ].
> >>
> >>
> >> of course, i should catch this error in test, so i can verify that:
> >>
> >> a) test is get notified upon synthetically made error
> >> b) no matter what i do inside error handler (up to 'Processor
> >> activeProcess terminate'), a finalization process continues working
> >> (or restarts without losing remainder of executors).
> >>
> >>
> >> Also, i used #ensure: and #ifCurtailed: but i tend to forget where
> >> they are applicable and how.
> >> So, little help in this regard will be wellcome.
> >>
> >> > Bill
> >> >
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >>
> >
> >
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101011/8882f3ad/attachment.htm


More information about the Squeak-dev mailing list