From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#16775: dbus interacts poorly with lisp-level event loops Date: Mon, 17 Feb 2014 05:52:54 -0800 Message-ID: <53021436.9080704@dancol.org> References: <5301EAE0.5080008@dancol.org> <5301EFB0.7000400@dancol.org> <87k3ctg993.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392645489 12310 80.91.229.3 (17 Feb 2014 13:58:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 13:58:09 +0000 (UTC) Cc: 16775@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 17 14:58:16 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 1WFOi8-0002ir-CP for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 14:58:16 +0100 Original-Received: from localhost ([::1]:40760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOi8-0003Z7-1k for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 08:58:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOe9-0005v3-BE for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:54:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFOe2-0004L5-Pd for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:54:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFOe2-0004Ky-GM for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WFOe1-0003ps-Ni for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 08:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Feb 2014 13:54: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.139264518314666 (code B ref 16775); Mon, 17 Feb 2014 13:54:01 +0000 Original-Received: (at 16775) by debbugs.gnu.org; 17 Feb 2014 13:53:03 +0000 Original-Received: from localhost ([127.0.0.1]:56044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFOd3-0003oC-L1 for submit@debbugs.gnu.org; Mon, 17 Feb 2014 08:53:02 -0500 Original-Received: from dancol.org ([96.126.100.184]:48461) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFOcz-0003o0-SG for 16775@debbugs.gnu.org; Mon, 17 Feb 2014 08:52:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=q9FQAbO4+AQpLqBkaVRmoZPvTNBnUUqY0wSaTpDqUsY=; b=kfxr1RsR30hxX88KFeTo0KXwjcyxytRfEBu+MyBBw4GBmy9jTbCYMU8KiWvOs3DvKt5kgkkOcLOZVqLs2m+4QY1kbkzjqnhV7fIMyZzzFkuF79HfY1t2WT17AySZl/p33iK5tTTeQXLmijZY5zNwm2CRYTMzI2VgJG+mxH7VUDMwUGjsJiPqyRvBf+1ifZWmWav8DLMZKCbl7NtjxajVba8geoYT2qToHZF569ecItvaa1rFMo+e/sIXFrsYC4ix5Mqx4/zo7cN6xiGNwomQMSq/xa82vAyLi3cIfhHREcn0jZMi+QJ3ZhcU62Y2Amht00pJCcbZT5vZYUe1OH/bjQ==; Original-Received: from c-76-104-210-106.hsd1.wa.comcast.net ([76.104.210.106] helo=[192.168.1.50]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1WFOcy-0008Rr-Cq; Mon, 17 Feb 2014 05:52:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <87k3ctg993.fsf@gmx.de> 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:85727 Archived-At: On 02/17/2014 05:27 AM, Michael Albinus wrote: > 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. Then why was it calling dbus-check-event on the result? I checked in a hack that addresses the immediate issue. > 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). Because secrets.el was taking a whole second to load due almost entirely to dbus delays. >> 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 goal is to make dbus-call-method return as soon as the method call is complete. >> 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. I find it hard to believe that the overall effects were intentional. Randomly delaying all of Emacs because something tried to make a dbus call is completely unacceptable. >> --- 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? No, because the current code is so broken that any example I gave wouldn't actually demonstrate the problem I'm trying to explain above: I wasn't expecting the desirability of random 100ms delays to be a point of debate, so I jumped right to the problems one might encounter with various solutions. You can trigger the scenario I'm worried about by performing a dbus call in an X drag-and-drop handler while somebody else is already blocked waiting for a dbus call. >> 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. I have a partial patch that implements this scheme: add another argument early-return to Fread-event and sit-for. early-return can either be nil for present behavior or a function of no arguments. Plumb early-return all the way down to wait_reading_process_output, and have that function call early-return just before running xg_select. If early-return returns true, abort the select loop and return nil from Fread-event. This way, you could pass into read-event in dbus.el an early-return function that checked for the existence of the return value on dbus-return-values-table. Then, the function would return immediately on a dbus call being complete no matter how deeply the calls were nested. The mechanism could also take over the role of the current wait_for_cell stuff.