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 inspect Not 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