Re: Power: blink-cursor-mode is a pig

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]

On 12/30/11 3:42 AM, Eli Zaretskii wrote:
>> Date: Fri, 30 Dec 2011 01:20:45 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: Emacs-devel@gnu.org
>>
>> Cursor blinking is _not_ implemented at a low level in C; if it were,
>> the problem would be more tractable.  The cursor blinking is triggered
>> by a lisp timer.  The display code (specifically,
>> get_window_cursor_type) can use a different kind of cursor depending on
>> whether a window is selected or not; that's why we don't observe the
>> cursor blinking when Emacs loses focus.  But the decision to show the
>> cursor or not happens on the lisp level, in blink-cursor-timer-function.
> 
> Timers are not Lisp-level creatures, they are fully implemented in C.
> They just call Lisp functions when the value of some variable becomes
> non-positive, but that's all they have to do with Lisp.  It should be
> very easy to avoid calling Lisp under some conditions known at the C
> level.

Timers are used for all sorts of things. How is the C layer supposed
to know the purpose of a particular timer? I don't want my
cursor-blinking timer to fire, but I might want jit-lock to keep
fontifying until it's done.

We could add a facility to allow lisp to communicate more information
about timers to the C layer --- perhaps some kind of timer metadata
meaning "run this timer only when Emacs has focus".  I consider this
solution very ugly.

> But I think I actually don't understand what you are trying to achieve
> exactly, and why, because I admit I don't know well what exactly is it
> that causes power waste due to "Emacs wakeups" you want to avoid.
> 
> 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.

(Right now, there is a bug that currently causes Emacs to wake up
every two seconds, but these wakeups are spurious, and I've sent a
patch to bug-gnu-emacs.)

>  A timer fires when this loop sees that the current time is
> past the timer's expiration time.  An idle time fires when the loop
> sees that Emacs was idle for more than the specified amount of time
> (i.e., the loop records when Emacs became idle and then compares the
> current time with that recorded time).  When the loop decides that a
> time expired, it calls its Lisp function.
> 
> (Btw, unlike what you say, blink-cursor-mode does _not_ use an idle
> timer.  But this is not important; I digress.)

blink-cursor-mode uses an idle timer to start the regular timer and
disables the regular timer in pre-command-hook.  It's a long story.

> Now, in the context of battery operation, why would you want to avoid
> calling the Lisp function, given that the loop which invokes that
> function will still be running?  How will that avoid waking up Emacs,
> when the fact that the loop is running already means Emacs is awake?

This paragraph rests on the invalid assumption I discussed above.
Emacs does not busy-wait.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]