Martin Geisler wrote:
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.
This solution is indeed not very elegant. The problem that has to be
solved here is the following: In a normal run every player (i.e. every
runtime) has its own reactor and this reactor runs
process_deferred_queue() of one runtime. In the unit tests however,
there is one reactor for n runtimes. Therefore the reactor has to call
process_deferred_queue() of every runtime. Now, if we just would
iterate as usual over the runtimes this would lead to very unbalanced
and therefore slower execution, because the loop call is called
recursively. So this construct is to ensure that every time
loop_call() is called, another runtime has first priority.

Is all this even necessary when the code calls self.activate_reactor
once in a while?

Yes because activate_reactor() lets the reactor call the loop call.

I sort of had the impression that it was not necessary
to activate the reactor explicitly -- do things no longer work correctly
without it?

The loop call is something different than activating the reactor. If reactor is a ViffReactor a proper loop call is mandatory, but not the reactor activation. In the case of a SelectReactor activate_reactor() shouldn't do anything, this is a mistake, which I will correct. I'll also make a patch to make the unit tests also run with a SelectReactor.

Also, the sending of messages is already delayed by a random amount, so
perhaps the unbalanced execution will be handled that way?

I don't think so.

viff-devel mailing list (

Reply via email to