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

and

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

?

> 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.