[Pharo-project] Announcement real problems - please read and comment.

Igor Stasenko siguctua at gmail.com
Mon Apr 4 13:16:29 CEST 2011


On 4 April 2011 12:55, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>
>>>>> Henrik what is your answer to problem 1
>>>>>
>>>>> Problem 1
>>>>>    - the second announcement was never sent, because the first one broke the second was blocked.
>>>>>    >>   we should make sure that if an announcement leads to an error, other annoucements on the same emit should pass
>>>>>
>>>>> Because we can get the system down just because one guy can register a bug.
>>>> http://forum.world.st/Another-finalization-concern-error-handling-td2989615.html
>>>>
>>>> It's basically the same.
>>> ??
>> Same basic problem, same solutions apply.
>> I'd rather not repeat the exact same discussion.
>> Just exchange "finalization" with "announcement delivery" when reading the thread
>
> Igor what was exactly the summary?
>

Summary, in short, is following:

we want to iterate over some arbitrary collection and perform an
action per each element, like:

collection do: [:each | each doSomeAction ]

but the problem here is that if one action triggers an error, then
your loop are interrupted and no other actions performed
for the remaining elements of collection.

So, we need such behavior , that guarantees that:
 a) all elements , except errorneous get processed
 b) if an error is unhandled by action , then show a debugger window

in terms of implementation this means that we should run each action
in separate forked process (and Eliot described a clever scheme how to
avoid most overhead of forking).

So then, even if some action will trigger an error, it won't interrupt
the loop and error could be handled in debugger

> Stef
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Pharo-project mailing list