Whilst it's not a good idea to have two electrum instances
open on the same wallet, we should avoid throwing an
exception. Also note how the old code's handling of the
exception (caused by both renaming the file almost at the
same time, rather than a non-POSIX system not supporting
the atomic rename) can lead to the wallet file being lost
enirely because os.remove(self.path) succeeds and the
rename of the temporary no-longer-existing file then fails.
switch_to_random_interface used to do is_connected()
checks and remove interfaces when switching. This
is redundant: interfaces are only added to self.interfaces
once in is_connected() state from process_if_notification().
When they are disconnected, a notification is also received
and process_if_notification() performs the removal. Furthermore,
two other callers of switch_to_interface do not do explicit
is_connected() checks before calling it.
Traceback (most recent call last):
File "src/electrum/lib/network.py", line 411, in process_request
out['result'] = f(*params)
UnboundLocalError: local variable 'f' referenced before assignment
[Network] network error local variable 'f' referenced before assignment
switch_to_interface() becomes the common place where
self.interface is set; therefore self.interface is not None
precisely when self.default_server is connected. Previously some
places required it to be connected and some didn't. Also an
interface change now sends the 'updated' notification
consistently - previously some did and some didn't.
Have network_start() call start_interfaces() - this also means
network restarts now do this.
Fix apparent off-by-one in start_interfaces()
Prefer to use safer self.is_connected() as it checks interface
is not None.
Using common code gives small observable changes in behaviour:
- slightly different print_error() messages
- network restarts now enter status 'connecting' which they
didn't before, which seems correct
- status 'connecting' is done with set_status() rather than
simply assigning the status, which seems more correct. Now
that the response_queue is available in the constructor this
works; it used to fail with 'response_queue is not defined'
This is somewhat cleaner as the proxy's pipe and network setup
was awkwardly interleaved. It also means network's constructor
is free to use both; currently some code is working around the
fact that the response queue doesn't exist in the constructor.
Found these issues while trying to create, sign, and broadcast a raw transaction.
* createrawtransaction was using old signature for Transaction constructor
* Signwithwallet and decoderawtransaction need to call deserialize on tx before they can access inputs and outputs. (Maybe adding getInputs() and getOutputs() which deserializes if needed might be nicer)
ThomasV
ThomasV
Neil Booth
mikeland86