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?
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.
Thierry
