Another finalization concern: error handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
On 12 October 2010 01:56, Eliot Miranda <[hidden email]> wrote:

>
>
> On Mon, Oct 11, 2010 at 3:07 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 12 October 2010 00:02, Eliot Miranda <[hidden email]> 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.

Thanks for clarification.
My english-fu is not good enough to express myself clearly.
I understood how it works a bit later after quickly responding to your messages,
and your explanation just puts last dots over i's.

So, if other gurus say yes, lets do it using forking, then i'll start
implementing it.
If there are better ideas how to do it even more efficiently (w/o
forking and keep it fault-tolerant),
i am all open to hear.

>>
> No.  They haven't patented the algorithm.  The code is freely accessible (its from vw non-commercial).  Just don't copy the code.

Good to know. Because infecting open source with badly
licensed/patented stuff will be the worst possible contribution :)

--
Best regards,
Igor Stasenko AKA sig.

12