inhibiting suspend via dbus

[John Gilmore]

> As it turns out, the activity update control panel needs to inhibit
> suspend, too, otherwise we go to sleep in the middle of downloading
> large activities (Firefox, TamTam, etc).
>
> Chris, could you make a little wiki page explaining how to interact w/
> ohm via dbus to temporarily inhibit suspend, and send me the [[link]]?
>  I figure other people who want to do other long-lived tasks could use
> this information, too; it should perhaps be included in the activity
> API docs.  (Does Browse properly inhibit suspend during download?  It
> probably should.)

No, this is the wrong approach.

We shouldn't be patching every program to "avoid suspending" at various
times.  We should be improving the heuristic that the system (Ohm) uses
to decide when to suspend.  Once we have better information from the
kernel about what the running processes are doing, we'd just have to
rip out all the little kludges inserted into every program.

Normally, when a TCP connection is active, even a suspended XO should
break out of suspend when the next packet arrives from the other end.
Only if it happens to suspend in the brief interval between receiving
that packet and asking for the next one, will such a suspend persist
indefinitely.  But there may be bugs there (e.g. #6528).

We already have bugs because Read was hacked to force suspends, and it
turns out it's suspending at the wrong times (#6645, #6684).  Let's
not add more bugs by hacking more activities to force or unforce
suspends.

We should understand why ohm isn't noticing that the activity updater
isn't idle.  Should Ohm be looking for a higher cpu idle% in the
seconds before it suspends?  Should it be looking for minimal numbers
of context switches per second before it suspends?  What does the
system look like when the updater is running?  If we can confine our
suspend-kludge patches to one place (ohm) we'll be much better off in
the medium and long term.

	John