2015-07-03 11:30 GMT+02:00 Henrik Johansen <[email protected]>:
> > > 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. > Ok. Then this could mean the following is possible: - Debugging an announcement delivery - With, say, system browsers not properly updated since their delivery is among the suspended deliveries. Or: - Debugging an announcement delivery - Have RPackageOrganizer out of sync (because its delivery is next) - And add a class or a method in this out-of-sync RPackageOrganizer. > > > > > 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 :) ) > Yes, it should be done that way in that particular case, but I believe we haven't solved it. It's the ClassModifiedClassDefinition event which has that behavior. > > 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. > If you work at that abstraction level, then that's fine. But it's not the case. A system browser has to subscribe to the low-level events ;) > > 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 > Which leads to the symptom of a random, not repeatable bug triggered by the particular ordering of the instance of the IdentitySet. Or a non-bug, but random behavior of the delivery. Had that in the Keymapping event handling. Hated that. I understand well the concern, but I honestly wonder if triggering random bugs helps. Regards, Thierry
