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.

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101011/9b0ac8be/attachment.htm