Previously, we were creating a stack beginning at the initial page,
and then growing it upwards. The correct behavior is to begin it at
the top and grow it downwards.
In order to do this, subtract the size of the stack from the initial
pointer.
Signed-off-by: Sean Cross <sean@xobs.io>
This is a "no good choice" situation but there is a problem with
progress bars.
You want progress bars to update quickly, and you don't want
to have to context switch out for the entire graphics stack to
come back to you to approve the drawing of your progress bar update.
On the other hand, you don't want to short-circuit all the checks
on drawing stuff to the screen for the sake of progress bars --
right now, there are a number of checks in place to make sure you
can't draw stuff on parts of the screen you shouldn't, to avoid
fake messages and dialog boxes.
I had managed to work out a way to get a dialog box to redraw without
violating the security rules -- each redraw is checked by the defacing
routine -- however, due to the way I was computing the height of
the modal I was causing the dialog box to be resized to its largest
size and then shrunk again to fit the text every iteration. This
in essence also caused the defacement routine to run repeatedly,
which caused the GAM to also issue repeated redraw requests to
the main loop.
These redraw requests can't be serviced until the task being tracked
by the progress bar is completed. As the progress bar gets redrawn
almost a hundred times as part of the task, roughly a hundred messages
arrive in the server's queue before it can handle a single one.
This results in a deadlock situation on completion of the progress
bar, because we want to fire off a message to ourselves to go to
the next state in the Ux routine.
There are a few possible solutions to this:
1. Multi thread the heck out of the routine doing the progress bar,
so the dialog box and the slider are each in their own threads
with their own responders and then the thing doing the computation
is doing some Mutex-guarded-Arc thing.
2. Do some very unsafe bodge to allow sliders to do direct draws
that are unchecked
3. Add a check so that if the size of the dialog box doesn't change,
defacement isn't recomputed and thus redraw messages aren't sent back.
(1) doesn't work for a number of reasons -- in a general case, it's
probably OK, but it does cause a lot more memory usage (and we are
lean on memory); but more importantly, for this use case, our routine
is interacting with CSRs and those don't implement Send so you can't
pass them into a thread via a closure. You could maybe put the dialog
boxes themselves into an Arc Mutex thing but because this routine
was heavily coded to re-use the heavyweight Ux resources this becomes
a bit cumersome to code.
(2) is terrible
(3) ended up working and what is in this commit. I think it's OK
because a progress bar generally doesn't require changing the
size of a window to update its state; therefore the redraw is
deface-safe (since you aren't changing the bounds of what you were
already approved to draw in). Of course, if you have some sort
of a progress bar implementation that changes the size of the messages
reported up top so that the dialog box has to change size over and
over again, you still end up in the deadlock situation!
This removes all custom string formatting from the `log-server`.
This should improve performance, because we're not roundtripping between
various archive formats. We instead do a single copy and operate
directly on that buffer. We also now write bytes directly, as opposed to
creating intermediate strings.
This fixes a memory issue that was introduced recently.
Signed-off-by: Sean Cross <sean@xobs.io>
