[viff-devel] Broken unit tests

[Marcel Keller]

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.