On 20 May 2011 19:33, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Igor,
>     I get the idea but I does one really need on:fork: ?  Why not add
> Exception>fork, a la Exception>pass?  So one writes
> [ self doSomething  ] on: Error do: [:ex | ex fork ].
> and if you want to specify a handler function you pass in a block:
>
> [ self doSomething  ] on: Error do: [:ex | ex fork: [block to handle error
> in another process here] ].

Good question.
You can implement it anywhere.
Except then how to correctly determine stack slicing point?

Exception>>fork: aBlock

  contextToSlice := thisContext sender home
?

see, the above is too fragile. Where the guarantees that you sending
#fork: inside a block, but not like:

Error new fork: [ .... ] ?

If you looked at implementation, i capturing the context of a method
before sending #on:do:
in this way, i know the stack slicing point beforehand.
But if i place it into exception, then correct behavior will have to
rely on developer's sanity that he using it as intended by design.
So, why putting pitfalls when we can avoid them?

My choice for stack slicing point was to let user to see the closure
context with on:do: while debugging,
otherwise it will be harder to determine the origin of code, which led
to error.

Right now, if you evaluate
[ 1/0 ] on: Error fork:[ :ex | ex pass ]

in debugger, you will see the 2nd bottom context will be an on:do: method,
and next one will contain the context for closure that is receiver of #on:do:
so in this way you can clearly see the method with exception handler,
who wanted to
handle errors in forked process.


> ?
> Further, re the finalization issue why are you so resistant to the
> tried-and-tested VW solution that's been in use for about a decade?

i am not resistant at all. I had no time to do that.
Actually, i came to this idea when looking at Henrik's code for Announcements..
and then i found that it can serve for both finalization and
Announcements (and lot of other critical places,
where you don't want to be killed by errors).
For instance , today i shown to Stef, that by placing it at single point in
WorldState>>doOneCycleNowFor: aWorld

we could avoid respawning UI process each time you open debugger.
You slicing the stack with error, putting it into forked process,
where you can do anything with it,
while UI process continues to run from known safe point.

So it solves more problems than just in finalization.

Also i think that it is more efficient: you pay the high price only
when it is necessary - when exception
happens, but if things go as expected , the overhead is minimal.
While in solution which you describing, the price was higher, since you have
to pass the finalizer to forked process and signal semaphore, and then
wait till it finish or fork another process.
And synchronization is not cheap, and moreover, you will have 1 extra
process hanging around all the time.

While now i can simply do:

executors do: [:executor |
   [ executor finalize ] on: Exception fork: [ :ex | ex pass ]
]


> best,
> Eliot


-- 
Best regards,
Igor Stasenko AKA sig.