From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: read-event in batch mode Date: Fri, 31 Jan 2014 10:34:23 -0500 Message-ID: References: <831tzo74oz.fsf@gnu.org> <87txckgtbk.fsf@gmx.de> <83txck5hbe.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391182483 13501 80.91.229.3 (31 Jan 2014 15:34:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 15:34:43 +0000 (UTC) Cc: Michael Albinus , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 31 16:34:50 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W9G7F-0007Id-86 for ged-emacs-devel@m.gmane.org; Fri, 31 Jan 2014 16:34:49 +0100 Original-Received: from localhost ([::1]:56379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9G7E-0001OK-Q8 for ged-emacs-devel@m.gmane.org; Fri, 31 Jan 2014 10:34:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9G75-0001Mp-Su for emacs-devel@gnu.org; Fri, 31 Jan 2014 10:34:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9G6y-00064j-Jp for emacs-devel@gnu.org; Fri, 31 Jan 2014 10:34:39 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:23410) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9G6q-000631-BP; Fri, 31 Jan 2014 10:34:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+J67/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYYl5kiCBXoMV X-IPAS-Result: Av4EABK/CFHO+J67/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYYl5kiCBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46497310" Original-Received: from 206-248-158-187.dsl.teksavvy.com (HELO pastel.home) ([206.248.158.187]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 31 Jan 2014 10:34:23 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9572E6035F; Fri, 31 Jan 2014 10:34:23 -0500 (EST) In-Reply-To: <83txck5hbe.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 31 Jan 2014 16:58:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169278 Archived-At: > The "keyboard buffer" is a misnomer: that's actually the Emacs event > queue, where all kinds of events end up, and from which they are read > and processed. Why is it a good idea to have more than one event > queue? Because some events should be processed in a particular order and others in a different order. They correspond to different "threads" of execution. The "keyboard buffer" normally corresponds to events coming from the user, so their relative ordering is very important and should not be changed. But D-Bus events or file-notification events may be triggered by processing that's completely independent/asynchronous from the user's actions, so they should be processed by Emacs without having to wait for previous user-events to be processed. The typical use case: user types a command which involves communication over D-Bus, then hit key "b", then the first command starts, sends some D-Bus message, waits for the answer: if the answer comes after key "b", we're in a "deadlock" where "b" won't be processed before the command is completed, but the command won't complete before the D-Bus answer is received and processed. Stefan