Hacker News Reader

Comment by markus_zhang | Hacker News Reader

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.

View on HN

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.

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.

The banker trying to close a deal isn't paid by the hour.

Unless the user's boss complained to the programmer's boss

> 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.

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.

Reply on news.ycombinator.com