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 04:39:42 -0800 Message-ID: <4EFDB10E.70701@dancol.org> References: <4EFCFDCA.6060802@dancol.org> <831urmv30g.fsf@gnu.org> <4EFD826D.2060309@dancol.org> <83pqf6theu.fsf@gnu.org> <4EFDA761.1040506@dancol.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CDB3C6C4E310B9CCC5F61DD" X-Trace: dough.gmane.org 1325248801 23823 80.91.229.12 (30 Dec 2011 12:40:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 12:40:01 +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 13:39:57 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 1Rgbkb-0002HC-Aa for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 13:39:57 +0100 Original-Received: from localhost ([::1]:42613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rgbka-00082T-Um for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 07:39:56 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:57021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgbkY-000827-BY for Emacs-devel@gnu.org; Fri, 30 Dec 2011 07:39:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgbkW-0003Zu-VV for Emacs-devel@gnu.org; Fri, 30 Dec 2011 07:39:54 -0500 Original-Received: from dancol.org ([96.126.100.184]:36191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgbkU-0003ZR-Bn; Fri, 30 Dec 2011 07:39:50 -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 1RgbkT-0001oG-45; Fri, 30 Dec 2011 04:39:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4EFDA761.1040506@dancol.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:147052 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CDB3C6C4E310B9CCC5F61DD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. --------------enig2CDB3C6C4E310B9CCC5F61DD 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 iEYEARECAAYFAk79sRAACgkQ17c2LVA10VsZTQCg416+S9SucBUAhuOUg9xZdaZl wN0AnRGpg9UvULajK0FFA4yFgfW70U88 =GC8V -----END PGP SIGNATURE----- --------------enig2CDB3C6C4E310B9CCC5F61DD--