3 ms·
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.
by ajkjk 2y ago
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.
- delusional 2y agoId 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.
- tedunangst 2y agoThe banker trying to close a deal isn't paid by the hour.
- immibis 2y agoUnless the user's boss complained to the programmer's boss
- skissane 2y ago> 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.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- saagarjha 2y agoSuspending 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.
- ajkjk 2y agoStack 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.)
- saagarjha 2y agoIt's like a hundred dereferences for native threads, that's not very much