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

Igor Stasenko siguctua at gmail.com
Mon Apr 4 17:06:16 CEST 2011

On 4 April 2011 16:38, Henrik Johansen <henrik.s.johansen at veloxit.no> wrote:
> On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote:
>> 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
> Or instead of forking each action, simply:
> (changed to make OC copy)
> deliver: anAnnouncement
>        | cls copy |
>        cls := anAnnouncement class.
>        "using a copy, so subscribers can unsubscribe from announcer "
>        "Use OrderedCollection , so unwind protection is easier"
>        self protected: [ copy := subscriptions as: OrderedCollection ].
>        self deliver: anAnnouncement to: copy
> (private category)
> deliver: anAnnouncement to: subs
>        subs do:
>                [:each |
>                [each deliver: anAnnouncement]
>                        ifCurtailed: [self deliver: anAnnouncement to: (subs after: each)]]

then probably you can do it in right place - in subscription>>deliver:
put ifCurtailed: handler.

> This has the added benefits of:
> - No thread creation overhead (Not sure if how it's written avoids creating a block for argument to each ifCurtailed call though)
> - Reproducibility.
>        Especially in the case Stephane gave, if you forking in separate threads, his code would appear to work when stepping in debugger.
>        There'd be mucho frustration and grumbling over announcements failing one second, but working the next. :)
> Downside is ofc that rest of subscribers won't be notified until you proceed/exit the debugger, but compared to reproducibility, that's a small price to pay imho.

Its really depends on use case, what is preferable behavior. For
instance if you stall in debugger when delivering UI events, then no
new events could be handled and you dead,
so in cases like this you cannot afford to stop handler from
processing events and wait for user intervention.

Also, i think it would be nice to disable a subscription, so it won't
receive any new announcements if it stopped under debugger, because if
you don't do that, and new announcements are flowing at some constant
rate, then you will have a tons of debugger
windows popping out and no way to stop that :)

> Cheers,
> Henry

Best regards,
Igor Stasenko AKA sig.

More information about the Pharo-project mailing list