From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Power: blink-cursor-mode is a pig Date: Fri, 30 Dec 2011 03:58:25 -0800 Message-ID: <4EFDA761.1040506@dancol.org> References: <4EFCFDCA.6060802@dancol.org> <831urmv30g.fsf@gnu.org> <4EFD826D.2060309@dancol.org> <83pqf6theu.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig841907AEE3ABFB3355E2F546" X-Trace: dough.gmane.org 1325246330 8482 80.91.229.12 (30 Dec 2011 11:58:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 11:58:50 +0000 (UTC) Cc: Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 12:58:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rgb6f-0003n4-79 for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 12:58:41 +0100 Original-Received: from localhost ([::1]:44132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgb6e-0003qt-RE for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 06:58:40 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:54955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgb6b-0003qk-Ju for Emacs-devel@gnu.org; Fri, 30 Dec 2011 06:58:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rgb6a-0005eH-B7 for Emacs-devel@gnu.org; Fri, 30 Dec 2011 06:58:37 -0500 Original-Received: from dancol.org ([96.126.100.184]:36112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgb6Y-0005d1-Fg; Fri, 30 Dec 2011 06:58:34 -0500 Original-Received: from c-24-18-179-193.hsd1.wa.comcast.net ([24.18.179.193] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Rgb6X-0001lJ-KN; Fri, 30 Dec 2011 03:58:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <83pqf6theu.fsf@gnu.org> X-Enigmail-Version: 1.3.4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.126.100.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147051 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig841907AEE3ABFB3355E2F546 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/30/11 3:42 AM, Eli Zaretskii wrote: >> Date: Fri, 30 Dec 2011 01:20:45 -0800 >> From: Daniel Colascione >> 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 o= n >> 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-functio= n. >=20 > 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. >=20 > 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. >=20 > (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. --------------enig841907AEE3ABFB3355E2F546 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk79p2gACgkQ17c2LVA10VtwQgCgk2cMII0GRhtv/uU7WhD3rYJt kXYAn0Zf1rI7bdwLQzUrTzCU9OU26gpm =7lGa -----END PGP SIGNATURE----- --------------enig841907AEE3ABFB3355E2F546--