> On 02 Jul 2015, at 9:40 , Thierry Goubier <[email protected]> wrote: > > Hi Henrik, > > Le 02/07/2015 10:49, Henrik Johansen a écrit : >> >> >> The whole thread at >> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2012-January/057478.html >> is >> a good read for insight into the thoughts behind the current implementation. >> While some of Lukas' complaints that related to artifacts of the live >> migration has been resolved, many of the decisions made wrt optimization >> target/robust delivery are still valid. > > Very interesting thread, thanks. > >> My thoughts are now as they were then wrt. forking delivery, it makes >> code both harder to debug, and is (imho) not a good tradeoff between >> performance/clarity and percieved benefit. >> I'd rather the handler be responsible for the decision of whether it is >> heavy enough to be forked off in order to not block other delivery, than >> enforce it as a default. > >> I haven't searched for the related thread, but the fork-on-exception >> behaviour was eventually argued down to only apply for UnhandledErrors. >> The ifCurtailed: block is still somewhat useful, it lets you do things >> like put halts in handlers, and still be certain remaining subscribers >> are notified if you close the debugger, rather than proceed. > > Ok, so the behavior on halt (or an error opened on debugger) is to suspend > all other notifications on that announcer? Including on the main system > announcer?
The behaviour is the same as when suspending any thread. If said thread is the only source of announcements, then all notifications are effectively suspended. There is nothing blocking other threads from delivering new announcements though. Unlike UnhandledErrors, a debugger raised responding to a halt will not have forked off in a separate thread, so you can navigate the entire stack, inspecting announcement source / other subscribers, etc. The ifCurtailed: merely ensures that if said process is terminated during delivery (Say, a debugger is closed instead of proceeded), the remaining subscribers will be processed before termination actually occurs. > > I do have some issues in one of the system announcement where strangely the > announcement is received before the real operation is undertaken, and this > makes handling it properly an interesting problem. That sounds like a pathological erroneous use of announcements we tried to make as hard as possible to actually get to work... There are two facets to this; 1. The announcer relies on a subscriber to do work for it. This is just *wrong*, in that it needlessly complicates things. As per above, this is the case if the system announcer announces that a method has been added, but the actual compilation / class installation happens in a subscriber. Instead, announce that the stuff has been done, at the same place it is being done, after it's done. (if that makes sense :) ) 2. You are subscribing to announcements at the wrong abstraction level. If, for instance, you want to refresh browsers based on updated package contents after a method has been added, you do not subscribe to a base system announcement that tells you code has been compiled and installed in a class. You subscribe to the PackageManager that announces a method has been added to a package. Cheers, Henry *One of the reasons an IdentitySet is used for subscriptions, instead of an OrderedCollection, was to make it harder to write code that relies on announcement delivery order without running into cases like the one you describe
