Comment 52 for bug 64326

Hello again Joe, sorry for the delay in replying.

(1) A full/initial scan (appears) to happen when there is no pre-existing index; such as on first-installation or upgrade. I'm suggesting that this huge gruntwork index /never/ takes place on battery power.

If my memory serves me correct, I have experienced what appears to be a never ending scan after an upgrade running on battery (this could have been an earlier development) and I quickly "kill -9'ed" this process.

(2) Yes, listening to HAL would be better for the battery/AC state querying than polling. What's the failure mode if the '/proc/acpi/ac_adapter' can't be opened. I'm wondering if perhaps some of the reports above are from machines with failed ACPI (or APM...). Would the daemon go into full-stream-ahead mode?

(3) For a slider to limit the extent of CPU|I/O that is occuring, perhaps suitable units could be in kilobytes/megabytes per limit; though I have a feeling that arbitrary units might be better this case. This is akeen to turning down the oven if the water is boiling over. I'd just turn the slider down until the condition (boiling over) is no longer occuring.

For the actual program there are probably *several* units. Load average, AC power, MB/second of block I/O, screensaver. Perhaps others? The daemon doesn't actually have to be using 100% CPU to bring a machine responsiveness down; could be as simple as starving other programs of disk I/O cycles I guess.

I'm as puzzled as you if Beagle is indeed not meant to ever run the CPU at full-whack.