Although I understand nothing from these posts, read Raymond's posts somehow always "tranquil" my inner struggles.
Just curious, is this customer a game studio? I have never done any serious system programming but the gist feels like one.
I would guess it's something corporate. They can afford to pause the UI and ship debugging traces home more than a real-time game might.
Suspending threads is generally not that expensive, especially if you don't do it very often. Like, it's not free, and don't do it every frame, but even if it takes even a millisecond (wildly overestimated) that's fine if you don't do it very often. Even if you're hitting a 120 Hz deadline.
Stack tracing, however, can be very costly. At least if you trace every thread.
(well, when I did it it was in python on python threads, which I have to assume is a lot worse. Not sure about native threads.)
Id actually expect a customer facing program more. Corporate software wouldn't care that the UI hung, you're getting paid to sit there and look at it.
> Corporate software wouldn't care that the UI hung, you're getting paid to sit there and look at it.
The article says the thread had been hung for 5 hours. And if you understand the root cause, once it entered into the hung state, then absent some rather dramatic intervention (e.g. manually resuming the suspended UI thread), it would remain hung indefinitely.
The proper solution, as Raymond Chen notes, is to move the monitoring thread into a separate process, that would avoid this deadlock.