The unglamorous week: shutdown, threading, and things that only fail sometimes

Not every week produces a feature. This one went almost entirely on the kind of defect that is invisible until it isn’t — the sort that fails once in twenty runs and is therefore easy to explain away.

• Closing the window now closes the application. Shutdown was racing itself: under certain conditions the first close was ignored, and under others the window could go away while the process stayed alive. There is now one shutdown path with one outcome, rather than several that mostly agreed.
• Every background task has an owner. Work started and forgotten is work that can fail silently, or take the process down from somewhere nobody is watching. Detached tasks are now owned and observed, which also removed a long-standing intermittent crash in the imaging path.
• One gate in front of the imaging library. The underlying Windows imaging API is not safe to call from several threads at once, and we were doing exactly that. Every call now goes through a single process-wide gate. The bug it fixes was rare, which is precisely why it had survived so long.
• The camera stays off the interface thread. Camera work was competing with drawing the window. Moving it off meant the interface stopped stuttering during capture, and camera recovery became deterministic enough to test properly rather than by observation.
• Telemetry admits what it cannot measure. A disk-usage reading that could not be taken was being reported as zero, which looks like a real measurement of an empty disk. It now reports as unavailable, which is what it is.

None of this is visible in a screenshot. All of it is the difference between a demo and something you would leave running.