On 12/30/11 3:58 AM, Daniel Colascione wrote:
>> Here's what confuses me.  Timers are implemented as part of the Emacs
>> internal loop that watches the various channels (keyboard, subprocess
>> pipes, network connections) for available input.  The loop that does
>> this is always running; it never stops, except for very short periods
>> of time.
> 
> The Emacs main loop does not busy wait!  When Emacs is not busy
> running lisp or doing other work, it waits blocked in select(2) until
> input arrives, a signal arrives, or the timeout given to select
> expires.  Emacs chooses the timeout by looking at all its pending
> timers and seeing which one will expire soonest.  If the next timer
> isn't due for an hour, Emacs will sleep for an hour before returning
> from select.  During this time, Emacs will use no power because it
> won't actually run --- the operating system maintains its own timer
> queue and wakes threads only when they need to run.

I should add that the machine as a whole does something very similar
to what Emacs does with its select timeout: the OS's thread scheduler
looks at what timers are scheduled across the entire system and puts
the CPU into a low-power state until the next one is due to expire.
That's why it's important for programs not to wake themselves up
unnecessarily: even one badly-behaved program can force the entire
system out of this low-power state.  When Emacs wakes up every 500ms
to uselessly blink an invisible cursor, it's just being rude, like
that kid we all knew in college who interrupted the professor every
other sentence.