I got another issue related to that i think.
In moose , at one moment in a announcement handling code, we are �doing:�Notification signal: 'Save successful!'.
That has for consequence that the on:fork: cuts the stack and I end up with a 'MessageNotUnderstood: receiver of "sender" is nil'.
So I don't know if the problem is that we are signaling a notification? if yes what should we use to notify something ?�

If you want to reproduce the bug, you can take this image:�http://dl.dropbox.com/u/12818380/Moose-26.zip
then right click on the selected model import-export / export to mse (I attached a screenshot showing that).





2011/5/27 Igor Stasenko <siguctua@gmail.com>
On 27 May 2011 12:05, Cyrille Delaunay <cy.delaunay@gmail.com> wrote:
> Hello,
> Today I experimented some strange behaviours with announcements that I
> didn't have in some previous moose images (moose in now based on Pharo
> 1.3).
> I think that there was some changes related to announcements in pharo
> recently, but I could not be sure it is related.
> At one point in my code I have:
> browser on: AnnouncementClass send: #actionSelector
> browser announce: anAnnouncementClass.
> ....
> ....
> The behaviour I have is like if #actionSelector was executed asynchronously
> from the rest of the code below 'browser announce: ...' .
> Not sure but there is maybe something with exception signals. If any signal
> is emited in #actionSelector it will not execute the rest of the method.
> I was at least able to write a test that do not pass in latest pharo 1.3
> Gofer new
> squeaksource: 'DelaunayTmpStuffs';
> package: 'ExampleAnnouncementProblems';
> load.

It was because on:fork: cuts the stack.
If you signaling exception in your code, you should handle it before
leaving your #actionSelector method.
Otherwise you may put the rest recipients of announcement in danger
and that's why there #on:fork: to prevent that.


--
Best regards,
Igor Stasenko AKA sig.