[viff-devel] Confusing behaviour?

[Marcel Keller]

I think the problem is the following: Every players sends its id on a 
new connection, and the connection is considered to be set up when this 
id arrives. So it may occur that a player has received the ids from all 
other players and wants to send its id to other player(s). But nothing 
is sent before all callbacks are executed. Since the player considers 
all connections to made, also the main callback, which blocks, is 
executed. Therefore, the problem is somehow related to what I'm working 
on because in a two-threaded solution the Twisted reactor is (nearly) 
never blocked. However, your problem probably could be fixed by 
synchronizing before blocking:

sync = runtime.synchronize()
sync.schedule_callback(blocking_code())

Thomas P Jakobsen wrote:
> Hi all,
> 
> When I execute the attached VIFF protocol on three servers I would
> expect all three to ask me to press enter. When all three servers have
> done that, I would expect the computation of c to start and that the
> servers will eventually finish.
> 
> I've run the protocol several times on Linux and Windows. What happens is this:
> 
> Sometimes it works out as expected, but at other times only two of the
> servers will ask the user to press enter. In some cases, the third
> server will ask its user to press enter as soon as one of the two
> other servers presses enter. At other times, the third server will
> first wake up and ask its user to press enter when both of the two
> first servers have pressed enter.
> 
> I find this behaviour confusing (..twisted?) and wonder whether it is
> a bug or a feature? If it's a bug, could it be related to the issue
> discussed in the thread "Mystery of the quadratic running time
> solved?". I must admit that I haven't followed that thread in
> detail...
> 
> By the way, the same thing seem sto happen if the protocol, insted of
> asking the user to press enter, does some local computations like
> quering a database, sleeping, computing primes or the like. Sometimes,
> one of the servers will sit still until one or both of the other
> servers have finished their local jobs. This was how I initially
> stumbled across the problem.
> 
> Best regards,
> Thomas