Writing [a.lock().unwrap().b.lock().unwrap()] sucks, so these are
some macros that are for common situations. This commit also has
a [sed] replace on all previous code that _could_ have been a macro,
which they all are now.
Hopefully nothing breaks :D
Even with the parent-child relationship and direct process handle,
Gupax can't kill an XMRig spawned with [sudo] on macOS, even though
it can do it fine on Linux. So, on macOS, get the user's [sudo]
pass on the [Stop] button and summon a [sudo kill] on XMRig's PID.
This also complicates things since now we have to keep [SudoState]
somehow between a [Stop] and a [Start]. So there is macOS specific
code that now handles that.
This commit takes care of correctly starting [sudo] with XMRig as
a command argument. The frontend [restart_*] function is also
implemented. In XMRig's case, the threads will sleep [3/5 seconds]
before [starting/restarting] so that [sudo] has time to open its
STDIN. This prevents premature inputs and outputting the password
to the STDOUT.
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.
