Announcement real problems - please read and comment.

>
> On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote:
>
>> On 4 April 2011 12:55, Stéphane Ducasse <[hidden email]> 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)]]
>

> On 4 April 2011 16:38, Henrik Johansen <[hidden email]> wrote:
>>
>> On Apr 4, 2011, at 1:16 29PM, Igor Stasenko wrote:
>>
>>> On 4 April 2011 12:55, Stéphane Ducasse <[hidden email]> 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.

>>>> 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.
>
> You don't have access to the remaining subscriptions in the subscription instances.
> ifCurtailed: sort of means "I'm about to terminate you (well, or do a non-local return, but that's never the case here), wanna do anything first?", so in my mind, the correct answer is the Registry saying "Hold on a bit, let me deliver to the remaining subscribers as well"
>
>>
>>>
>>> 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.
>
> Oh I agree.
> I'd argue that is the exceptional exception case (:D) where you'd want a specialized announcer rather than the other way around though. :)
> Prolly just me, but even in this case I'd favor a stacktrace which makes sense over a system which kinda sorta keeps on working when I do something horribly wrong.
>
>> 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 :)
>
> You'd definitely need an Error handler for that, yeah. It not mutually exclusive with using ifCurtailed: protection though.
>
> Cheers,
> Henry
>
>
>

> Short summary (not guaranteed to be 100% objective)
>
> Curtailing ->
> - Your image may crash in some cases, more specifically if you:
> 1) have errors in subscribers to announcements made in system-critical processes, as they will be suspended while debugging.
> 2) deliver announcements in a separate thread from where they're announced, and the announcing thread does so regularily.
> + Easy to debug. Entire call-chain available, no modification to state caused by subsequent subscribers. Restart should always lead in bug being reproduceable.
>
> The remove-from-subscriptions part of Error-handling and ifCurtailed could be combined as well, in which case #2 no longer applies.
>
> Error handling ->
> - Hard/impossible to debug because:
> 1) If your error was in ordering, debugger will step through flawlessly if restarted.
> 2) You start at the context of the subscriptions action, no idea where it came from.
> + More robust, none of the cases mentioned in Curtailing will crash your image.
>
>
> With the different pros/cons mentioned above in mind, here are .cs with example implementations for what  both Igor / I would like. (minus remove-from-subscriptions for ifCurtailed: )
>
> Cheers,
> Henry
> <AnnouncementErrorHandling.zip>