Blocking suspend blockers

Posted May 22, 2010 8:19 UTC (Sat) by quintesse (guest, #14569)
In reply to: Blocking suspend blockers by dlang
Parent article: Blocking suspend blockers

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

to post comments

Blocking suspend blockers

Posted May 22, 2010 18:48 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

But that's a problem the system has to deal with anyway, the user can yank out the cable at any time.

The system more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Blocking suspend blockers

Posted May 22, 2010 22:00 UTC (Sat) by sfeam (subscriber, #2841) [Link] (1 responses)

The system has more options to deal with the user yanking out the cable, because the user expects yanking the cable to interrupt use of the device, and the user can arrange not to yank the cable if it is a problem. In contrast, suspend happens all by itself at largely arbitrary times, so the user won't expect interruption and can't practically avoid it.

Huh? The point is that suspend/resume should be harmless with respect to a device that is still plugged in.

If the device is still plugged in when the system resumes, open files should still be open, etc. This already works with the hard drive; is it really so hard to re-establish communication with a usb device?
If the device is gone when the system resumes, that's a problem, yes. But it's the same problem as just yanking the cable while the system is active. Or hold on, it's actually a less serious problem, because we should have been smart enough to sync during the suspend process, whereas there was no opportunity to do so during the cable yanking.

Blocking suspend blockers

Posted May 22, 2010 22:32 UTC (Sat) by giraffedata (guest, #1954) [Link]

Oh, I misunderstood "connected" as in the device may not be connected when the system wakes up. "Connected" is a logical state to me, but I can see it was supposed to mean plugged in.

I agree. There's no issue with a cable being yanked while the system is asleep that doesn't also exist for the cable being yanked while it's awake.

Well, except that since going to sleep correlates with a lull in user activity, there's a higher chance of that yank happening while the system is asleep. But since preventing the sleep won't prevent the lull in user activity, I don't suppose that's relevant to the question of whether suspension should be blocked.