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

Henrik Johansen henrik.s.johansen at veloxit.no
Mon Apr 4 16:38:27 CEST 2011

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)]]

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.


More information about the Pharo-project mailing list