I'm trying to decompose some procs that perform numerous tasks, but have to do
it all while holding a single mutex to ensure the (global,
can-be-messed-with-at-any-time-by-another-thread) state one task leaves behind
is the same one the next works with. If I make procs that access the app state
without themselves acquiring the lock, I have to remove the guard pragma and I
open myself up to forgetting. The compiler doesn't recognize if a proc is
called only within a `withLock`, it requires that the proc itself take the
lock. The ideal solution would be if I could mark procs as "only to be called
while the thread holds the lock", but the `{.guard.}` pragma doesn't work like
that and I haven't found anything that looks like it would do the trick in the
docs.
Could it be that this issue is giving away bad design? Maybe the fact that my
tasks are intended to be atomic means I should keep them atomic within the
code, even if that means long, confusing procs.
