On 11.07.2012 15:41, Camillo Bruni wrote:
On 2012-07-11, at 15:28, Henrik Sperre Johansen wrote:On 11.07.2012 15:14, Camillo Bruni wrote:On 2012-07-11, at 15:02, Stéphane Ducasse wrote:On Jul 11, 2012, at 11:05 AM, Camillo Bruni wrote:That was a weird bug... but I fixed it. We need a Debugger for the announcement system!What do you mean? Because what I know is that debugging the test of announcement can be a pain because registrations are done in another world.the problem is, that on:fork: and co are used in the WeakMessageSends and thus lose the complete reference to where they came from..I tried to refactoring a bit so you can get a clue what's going on when stepping through with the debugger…What you describe is more related to the state of the debugger and yes it was on our todo to fix the debugger.no no, when you do SubscriptionRegistry >> #deliver: you create a complete copy of the subscriptions collection. This is not very useful, since you can filter them while copying => less items to copy, easier to inspectNot threadsafely.? this has absolutely nothing to do with thread safeness....
You're right, I'd forgotten exactly what we'd done :)
In my mind it still read something like:
deliver: anAnnouncement
subscriptions copy do: [:each | each deliver: anAnnouncement ],
relying on atomicity implicit through copy primitives rather than
explicitly with a mutex.
Filtering with the standard collection methods leaves you with an IdentitySet though, so you'd have to either convert it afterwards, change the curtailing code in deliver:to: (which uses Sequenceable protocol). Either probably has some tradeoff in readability/performance compared to the current delivery.
Cheers, Henry
