This allows for `ditherpunk` config to have a much larger
stack size on select processes only.
The cost comes at a 4k fixed overhead for the sacrificial
wrapper thread, so we lose about 20k of runtime RAM, even
when ditherpunk is *not* activated (because we're
always wrapping the threads).
There is no impact on scheduling or CPU utilization, as the
wrapper thread blocks and is never scheduled once the real
main starts. However, it does subtract one thread from the
total available thread pool.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
change the notification modal to accept the primary message and an
Option of independent text to display as a qrcode
pub fn show_notification(&self, notification: &str, qrtext:Option<&str>) -> Result<(), xous::Error> {}
This is a start on issue #111, where instead of starting a throw-away
server and doing a "yield" loop to emulate blocking behavior, messages
are instead stored so they don't drop, thus keeping a blocking
message blocking.
This call was originally part of the RTC driver, but when we
refactored things out, this was forgotten.
So, what would happen is, if you did a coldboot or reboot,
an alarm would get set and...well, the way the RTC blocks
is it'll keep asserting the alarm until you clear it.
This prevents the system from sleeping, and also keeps
the CPU pegged at 100% for some reason. The prevention
from sleeping makes sense to me. The CPU at 100% probably
indicates there's a problem in the event router, but
this path isn't used for anything at the moment so
we'll just open an issue and leave it as technical debt.
modals don't work when triggered in the status thread in hosted
mode (but they do, somehow, on real hardware). I think this
is an actual locking problem that would exhibit itself if
we had a true multiprocessor system, but since real hardware
is a single processor it doesn't show.
