monzero-core.git/contrib, branch v0.9.1Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.9.12016-01-03T11:57:35ZARM chars are unsigned2016-01-03T11:57:35ZHoward Chuhyc@symas.com2016-01-03T11:57:35Zurn:sha1:a561afa18b5e0bf82c890d99fb0caafaee2da80cIP_TOS not supported before Windows72016-01-02T03:10:41ZHoward Chuhyc@symas.com2016-01-01T02:47:48Zurn:sha1:ee6f2cb71f4053b58be1ea15bcbe099062bbbd7cupdated copyright year2015-12-31T06:39:56ZRiccardo Spagniric@spagni.net2015-12-31T06:39:56Zurn:sha1:de0392685063d93dbdad3a6b1a2712eaf94dd51aepee: regularly cleanup connections we kept a reference to2015-12-23T11:19:16Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-23T11:19:16Zurn:sha1:22581a04415c571461368c434ece72e5756d4fbd
Since connections from the ::connect method are now kept in
a deque to be able to cancel them on exit, this leaks both
memory and a file descriptor. Here, we clean those up after
30 seconds, to avoid this. 30 seconds is higher then the
5 second timeout used in the async code, so this should be
safe. However, this is an assumption which would break if
that async code was to start relying on longer timeouts.
epee: fix hang on exit2015-12-22T12:39:02Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-22T12:31:22Zurn:sha1:1e2f2d7da0ee22e35670856ad964671848e186b4
When the boost ioservice is stopped, pending work notifications
will not happen. This includes deadline timers, which would
otherwise time out the now cancelled I/O operations. When this
happens just after starting a new connect operation, this can
leave that operations in a state where it won't receive either
the completion notification nor a timeout, causing a hang.
This is fixed by keeping a list of connections corresponding
to the connect operations, and cancelling them before stopping
the boost ioservice.
Note that the list of these connections can grow unbounded, as
they're never cleaned up. Cleaning them up would involve
working out which connections do not have any pending work,
and it's not quite clear yet how to go about this.
epee: make log macros behave like statements2015-12-19T14:48:52Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-19T14:48:02Zurn:sha1:760331b427af7f0158019a14e7d210f771c9f8ca
In particular, make this kind of thing do what one expects
it to do:
if (x) LOG_PRINT("True"); else LOG_PRINT("No");
console_handler: catch exception inside the input loop2015-12-06T22:03:53Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-12-06T22:03:53Zurn:sha1:4cede1830e02966cf0a51f0425b7cf8a2bf13bce
This prevents an exception from existing the loop without
calling the exit handler, if one is defined.
The daemon defines one, which stops the p2p layer, and will
only exit once the p2p layer is shut down. This would cause
a hang upon an exception, as the input thread would have
exited and the daemon would wait forever with no console
user input.
Merge pull request #5072015-11-29T22:19:47ZRiccardo Spagniric@spagni.net2015-11-29T22:19:44Zurn:sha1:bc1bc4adb246b08adee2144ce2c7e3784f7899f1
62e49a5 wallet: optional automatic refresh from the daemon (moneromooo-monero)
wallet: optional automatic refresh from the daemon2015-11-28T12:41:06Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-11-28T12:38:58Zurn:sha1:62e49a5f02da0963fb0303383626b2c86443d405
The daemon will be polled every 90 seconds for new blocks.
It is enabled by default, and can be turned on/off with
set auto-refresh 1 and set auto-refresh 0 in the wallet.
core_rpc_server: add a --restricted-rpc option2015-11-27T18:27:24Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2015-11-27T18:24:29Zurn:sha1:75742977a8cd765175c1d3e39e2e74d25c6ca774
It does not expose the RPC for commands like start_mining, etc
(ie, commands a public node operator might want to be restricted)