Why do idle handlers suddenly hog CPU?

Or more precisely, the shell script within the idle handler hogs the CPU.

I have several simple applets (“Application bundle”) that do little tasks for me, such as play a silent sound every 20 seconds to prevent my laptop’s sound circuit from sleeping and producing a “pop” from my speakers when it comes back on, for example:

on idle
do shell script “afplay ‘/Users/[user]/Library/Sounds/Silentium.aif’”
return 20 – (Execute this idle handler once every twenty seconds.)
end idle


on idle
do shell script "say ’ ’ "
return 20
end idle

Such applets executing shell scripts do fine when first launched, but minutes or hours later suddenly start sapping enormous amounts of CPU usage. In Apple Activity Monitor, I can see that the offender isn’t the applet itself, but rather the called shell scripted process (“afplay” or “say” in the above examples, respectively).

Once the CPU-hogging occurs, I can quit and relaunch my AppleScript applet, but the gorging continues. I have to reboot to get good behavior again (until the congestion rears its ugly head once more).

Does this happen to anyone here, and what is the culprit? I recognize that this may have nothing to do with AppleScript proper, but I thought I’d start here.

Leopard 10.5.8

Model: MacBook Pro (5,2) “Mid-2009”
AppleScript: 2.0.1
Browser: Firefox 4.0.1
Operating System: Mac OS X (10.5)

Hi. I believe that “return 20” is more processor intensive than would be “delay 20”.

Thanks for the prompt reply, Marc, but two things:

  1. Even if that were true, I think it would be a moot point: As I stated in the original post, Apple Activity Monitor flags the CPU hog as the process called by the shell script, not the AppleScript applet containing the idle handler itself.

  2. I’m no AppleScript expert, but for whatever it’s worth, I chose my scheme based on a comment by AppleScript & other software developer Gregory Tetrault over at Softpedia that I saw on a thread at MacinTouch regarding this very issue. I can’t link to the thread because it was back in July 2011 and doesn’t seem to be there any longer, so I’ll just quote the pertinent excerpts from my notes, which suggest that the “delay 20” would be more processor-intensive, or at least more processor-troublesome in some other respect:

In any event, we digress off-topic, and I really need to hear from someone who may have experienced this CPU-hijacking by the called shell script process, and what they did about it.

What if you run the shell command in the background?

No, it’s the other way around. But wither way, the problem here seems to be in the shell commands, not AS.

If you meant run the AppleScript applet in the background, I already routinely have been doing that with the offending ones ” using the good ol’ LSUIElement trick. But if you meant running the called shell script in the background, I don’t know the command or syntax for that.

Right, at least that’s what Activity Monitor shows. But I got to thinking about it, and like I said, at first it runs without misbehaving, and only after some time suddenly starts to sap CPU activity, so maybe what’s getting out of whack is the Apple Events associated with calling the shell script, but the overhead shows up in Activity Monitor under the shell script process, I dunno.

Hopefully someone here will surface who’s actually experienced this curiosity, and investigated it, and will have some insight to share… Meanwhile, thanks, all of you, and keep 'em coming.

Nice idea, but it’s not really possible.