There's not much interesting data I could display that regular
Monero GUI or a block explorer can't do, so I'm scrapping the
[Monero] tab. Maybe it'll come back if I rewrite [Status] to include
graphs (never).
The [P2Pool] submenu is pretty much done, this changed the spacing
to make the logs larger and so all the elements fit correctly.
General cleanup and optimizations. Some functions are fixed,
some were turned into [const fn], and other small stuff like
[AtomicUnit] using a [u64] instead of a [u128]
These couldn't be fit in before since there wasn't enough space.
They still can't all fit in, but the most important ones can be
after adjusting the font sizes and height spacing.
If the user fullscreens, restricting to the 4:3 aspect ratio
doesn't make sense, so change the test for only the default/min.
Max is 4k since... who owns 8k monitors :D
Includes some small fixes:
- [localhost] will always be changed to [127.0.0.1] in the case
of XMRig (it doesn't understand localhost by itself)
- P2Pool/XMRig API path now checks for a [/] or [\]
and correctly applies the endpoint, e.g:
BASEPATH = "/home/hinto/p2pool"
ENDPOINT = "local/stats"
if BASEPATH doesn't end with '/' { BASEPATH.push('/') }
API_PATH = BASEPATH + ENDPOINT ("/home/hinto/p2pool/local/stats")
- P2Pool payout line got changed in: be18ad4177
The regex is now a more generic: [payout of [0-9].[0-9]+ XMR]
Keyboard shortcuts [Left] & [Right] were clobbering the
[TextEdit] left/right movement, so they are now [Z/X].
The shortcuts also look to make sure a TextEdit isn't
in focus so that [S/R/Z/X] can actually be typed.
P2Pool/XMRig now make sure the path ends with an [ACCEPTABLE_*]
value (e.g: P2pool, P2POOL) before enabling the [Start] UI.
Fixes:
- Up/Down only work if UI is enabled
- Re-pushed [P2POOL_API_PATH] to popped relative path
but only after giving the popped path to P2Pool
1. [/tmp/gupax/p2pool/p2pool] -> [/tmp/gupax/p2pool]
2. Give that to P2Pool
3. [/tmp/gupax/p2pool] -> [/tmp/gupax/p2pool/local/stats]
4. Give that to the watchdog (so it can read it)
There was a deadlock happening between the [Helper]'s [gui_api_p2pool]
and the GUI's [gui_api_p2pool], since the locking order was different.
The watchdog loop locking order was fixed as well. This was a pain to
track down, better than a data race... I guess.
Oh and keyboard shortcuts were added in this commit too.
Comment from code:
// The ordering of these locks is _very_ important. They MUST be in sync
// with how the main GUI thread locks stuff or a deadlock will occur
// given enough time. They will eventually both want to lock the [Arc<Mutex>]
// the other thread is already locking. Yes, I figured this out the hard way,
// hence the vast amount of debug!() messages.
//
// Example of different order (BAD!):
//
// GUI Main -> locks [p2pool] first
// Helper -> locks [gui_api_p2pool] first
// GUI Status Tab -> trys to lock [gui_api_p2pool] -> CAN'T
// Helper -> trys to lock [p2pool] -> CAN'T
//
// These two threads are now in a deadlock because both
// are trying to access locks the other one already has.
//
// The locking order here must be in the same chronological
// order as the main GUI thread (top to bottom).
Instead of cloning the entirety of the process's output, this
commit adds a sort of hierarchy of string buffers:
We need:
1. The full output for stat parsing (max 1 month/56m bytes)
2. GUI output to be lightweight (max 1-2 hours/1m bytes)
3. GUI output buffered so it's on a refresh tick of 1 second
------------------------------------------------------------------
So this is the new buffer hierarchy, from low to high level:
[Process] <-> [Watchdog] <-> [Helper] <-> [GUI]
------------------------------------------------------------------
Process: Writes to 2 buffers, a FULL (stores everything) and
a BUF which is exactly the same, except this gets [mem:take]n later
Stuff gets written immediately if there is output detected.
Watchdog: [std::mem::take]'s [Process]'s BUF for itself.
Both FULL and BUF output overflows are checked in this loop.
This is done on a slightly faster tick (900ms).
Helper: Appends watchdog's BUF to GUI's already existing [String]
on a 1-second tick.
GUI: Does nothing, only locks & reads.
------------------------------------------------------------------
This means Helper's buffer will be swapped out every second, meaning
it'll almost always be empty. Process's FULL output will be the
heaviest, but is only used for backend parsing. GUI will be in the
middle. This system of buffers makes it so not every thread has to
hold it's own FULL copy of the output, in particular the GUI thread
was starting to lag a little due to loading so much output.
Lots of stuff in this commit:
1. Implement [Start/Stop/Restart] and make it not possible for
the GUI to interact with that UI if [Helper] is doing stuff.
This prevents the obviously bad situation where [Helper] is in
the middle of spawning P2Pool, but the user is still allowed to
start it again, which would spawn another P2Pool. The main GUI
matches on the state and disables the appropriate UI so the
user can't do this.
2. Sync P2Pool's [Priv] and [Pub] output so that the GUI thread
is only rendering it once a second. All of Gupax also refreshes
at least once a second now as well.
3. Match the [ProcessState] with some colors in the GUI
4. GUI thread no longer directly starts/stops/restarts a process.
It will call a function in [Helper] that acts as a proxy.
5. The tokio [async_spawn_p2pool_watchdog()] function that was
a clone of the PTY version (but had async stuff) and all of the
related functions like the async STDOUT/STDERR reader is now
completely gone. It doesn't make sense to write the same code
twice, both [Simple] and [Advanced] will have a PTY, only
difference being the [Simple] UI won't have an input box.
6. P2Pool's exit code is now examined, either success or failure
7. Output was moved into it's own [Arc<Mutex>]. This allows for
more efficient writing/reading since before I had to lock all of
[Helper], which caused some noticable deadlocks in the GUI.
8. New [tab] field in [State<Gupax>], and GUI option to select
the tab that Gupax will start on.
