[Pharo-project] Announcement real problems - please read and comment.
stephane.ducasse at inria.fr
Mon Apr 4 17:42:38 CEST 2011
Ok guys so I want a solution :).
So how can we improve Announcement to cover different cases?
>>>> 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.
More information about the Pharo-project