Browse Source
interfaces we have created. Existing code has the concept of pending servers, where a connection thread is started but has not sent a connection notification, and and interfaces which have received the notification. This separation caused a couple of minor bugs, and given the cleaner semantics of unifying the two I don't think the separation is beneficial. The bugs: 1) When stopping the network, we only stopped the connected interface threads, not the pending ones. This would leave Python hanging on exit if we don't make them daemon threads. 2) start_interface() did not check pending servers before starting a new thread. Some of its callers did, but not all, so it was possible to initiate two threads to one server and "lose" one thread. Apart form fixing the above two issues, unification causes one more change in semantics: we are now willing to switch to a connection that is pending (we don't switch to failed interfaces). I don't think that is a problem: if it times out we'll just switch again when we receive the disconnect notification, and previously the fact that an interface was in the interaces dictionary wasn't a guarantee the connection was good anyway: we might not have processed a pending disconnection notification.283
Neil Booth
10 years ago
1 changed files with 19 additions and 20 deletions
Loading…
Reference in new issue