Hi Marcel, All the tests in the buildbot are currently broken:
http://buildbot.viff.dk/waterfall It is because of this change of yours: @@ -164,6 +166,18 @@ # the Runtime, since we want everybody to wait until all # runtimes are ready. self.runtimes.append(result) + self.real_runtimes.append(runtime) + self.i = 0 + + # This loop call should ensure the queues of the parties are + # processed in a more or less fair manner. This is necessary + # because we have only one reactor for all parties here. + def loop_call(): + for runtime in self.real_runtimes[self.i:] + self.real_runtimes[:self.i]: + runtime.process_deferred_queue() + self.i = (self.i + 1) % len(self.real_runtimes) + + reactor.setLoopCall(loop_call) I'm very confused about what exactly for x in xs[i:] + xs[:i]: ... i = (i + 1) % len(xs) is supposed to do? After x has run through all xs (rotated i steps), then i will have been incremented by len(xs). But you do it mod len(xs) and so i comes out of the loop unchanged. The xs[i:] + xs[:i] construct is at best uncommon and at worst wasted work. Instead of rotating the list, it should be enough to start at an offset (i) and work your way through the list with proper wrapping at the end. Also, the fact that you have both self.runtimes and self.real_runtimes smells funny :-) It's as if you're circumventing the natural scopes of the Deferreds by storing a reference to the runtimes "on the side". The list of Deferreds in self.runtimes ought to be enough -- can you not add callbacks to that list if you need something to happen when the runtimes are ready? -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
