From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#16775: dbus interacts poorly with lisp-level event loops Date: Mon, 17 Feb 2014 14:27:04 +0100 Message-ID: <87k3ctg993.fsf@gmx.de> References: <5301EAE0.5080008@dancol.org> <5301EFB0.7000400@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392643695 23647 80.91.229.3 (17 Feb 2014 13:28:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 13:28:15 +0000 (UTC) Cc: 16775@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 17 14:28:22 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WFOF9-0002mK-Mk for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 14:28:19 +0100 Original-Received: from localhost ([::1]:40494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOF9-0005NN-4j for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 08:28:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOEz-0005NB-MV for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:28:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFOEt-0003YT-6i for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:28:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54846) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOEt-0003YM-34 for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:28:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WFOEs-000383-19 for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Feb 2014 13:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16775 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16775-submit@debbugs.gnu.org id=B16775.139264364011965 (code B ref 16775); Mon, 17 Feb 2014 13:28:01 +0000 Original-Received: (at 16775) by debbugs.gnu.org; 17 Feb 2014 13:27:20 +0000 Original-Received: from localhost ([127.0.0.1]:56028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFOEB-00036u-41 for submit@debbugs.gnu.org; Mon, 17 Feb 2014 08:27:19 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:49536) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFOE7-00036c-GZ for 16775@debbugs.gnu.org; Mon, 17 Feb 2014 08:27:16 -0500 Original-Received: from detlef.gmx.de ([93.209.82.193]) by mail.gmx.com (mrgmx003) with ESMTPS (Nemesis) id 0Lhfu5-1X2FhL1onJ-00mqOM for <16775@debbugs.gnu.org>; Mon, 17 Feb 2014 14:27:07 +0100 In-Reply-To: <5301EFB0.7000400@dancol.org> (Daniel Colascione's message of "Mon, 17 Feb 2014 03:17:04 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:bzbFh10mko1B08X45gO/yihWhlYkAoPAKwakIZDu8fr5B7u3HXu L/PTqibGbw2yPQqgz7uPWOw+lDjyjaDBcUAioE8LouyNYtcOrwB98oKOs1lgw2zbcANrAcl uatWGV4Gy8omim4G4f/0tscOUpTMHCLw2EaIB+TCj9FZOtVERjvIsI1rQHDW1gVzPZgrycS 1n6Wviv1iwSbKrAeutrsQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85726 Archived-At: Daniel Colascione writes: > dbus-call-method expects read-event to return the dbus event > immediately, but read_char in keyboard.c treats the dbus event as a > special event and runs it through special-event-map itself before > sitting and reading another event. The event waiting loop always times > out, so dbus-call-method always takes at least 100ms due to the > hard-coded 0.1 timeout parameter to read-event. dbus-call-method does not expect the D-Bus event to be returned by read-event. It simply calls read-event in order to trigger event handling. The loop itself checks, whether the respective event has been inserted into dbus-return-values-table. And when *other* but D-Bus events do arrive in the meantime, they must be preserved in unread-command-events. Why is it a problem to wait at least 100ms? D-Bus messages are not expected to perform in real time (whatever this means). > This problem is hairy: special-event-map functions can execute arbitrary > code and re-enter the dbus synchronous event loop, and there's no way to > non-locally terminate a particular read-event loop. Here's the > problematic scenario: dbus-call-method works by setting up an > asynchronous dbus call and calling read-event until the specific > asynchronous call on which it is waiting completes. Why do you want to terminate non-locally in dbus-call-method? If you need asynchronous behaviour, there is dbus-call-method-asynchronously. > The immediate problem is that read-event never actually returns because > the dbus event is special As said above this is not a problem but intended. > --- but let's say we worked around that > problem by modifying special-event-map around the read-event call so > that read-event returned immediately. We'd still have a serious issue > because *other*, non-dbus special event handles can run arbitrary code > and enter an inner dbus-call-method reply-waiting loop. If the reply to > the outer synchronous dbus call arrives before the reply to the inner > synchronous dbus call, dbus-call-method-handler (which is run from > special-event-map inside read-event or, in our hypothetical partial fix, > manually from the wait loop) will dutifully put the reply on > dbus-return-values-table. But the inner event loop has no way of waking > the *outer* event loop, so when the special event handler that called > the inner dbus-call-method returns, read_char will loop around and wait > for the full timeout period before returning to the outer dbus-call-method. I don't understand the scenario. Could you, please, give a code example? > If dbus had been implemented as a process type instead of a special > event source, we'd just be able to use accept-process-output in dbus-call. There is already the discussion that such events (dbus, file notification) should be implemented differently. I don't know whether this shall be done as process type or as a separate queue to be checked for. Best regards, Michael.