On 09.09.2011 14:00,
[hidden email]
wrote:
2011/9/9 Tudor Girba [hidden email]:
> Igor and Stef can provide more details.
>
> The reason for forking is that even if one announcement breaks, the others should still be announced.
You don't need forking to do this. A simple exception handler would
work very well and not break any code. It just doesn't make you look
clever.
cheers
Philippe
Which is why it was changed, after discussion with Lukas.
It only forks UnhandledErrors now, before delivering the remaining.
As long as there is no abnormal termination, it will work just as
before.
If any subscribers would abnormally terminate though, the
ifCurtailed: kicks in, and (was supposed to) ensure delivers to
remaining subscribers.
If something in Seaside relies on such behaviour (like terminating
current process in order for subsequent subscribers to not receive
the announcement) that will be broken.
I don't think messing with announcement delivery should be
considered a good control flow mechanism though.
What Esteban encountered as an error on some VM's was a pure bug I
made in the ifCurtailed: block (by using after: instead of
copyAfter:), and had nothing to do with forking.
Why some VM's considered the delivery abnormally terminated, while
others didn't, I have no idea though...
(The error he got only happens when the ifCurtailed block is
invoked).
Cheers,
Henry
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
