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.

▲

saagarjha 8 months ago | parent | next [-]

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.

▲

ajkjk 8 months ago | parent [-]

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

	▲	saagarjha 8 months ago \| parent [-]
		It's like a hundred dereferences for native threads, that's not very much

▲

8 months ago | parent | prev | next [-]

[deleted]

▲

8 months ago | parent | prev | next [-]

[deleted]

▲

delusional 8 months ago | parent | prev [-]

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.

	▲	skissane 8 months ago \| parent \| next [-]
		> 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.
	▲	tedunangst 8 months ago \| parent \| prev \| next [-]
		The banker trying to close a deal isn't paid by the hour.
	▲	immibis 8 months ago \| parent \| prev [-]
		Unless the user's boss complained to the programmer's boss