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 16:57:27 +0100 Message-ID: <87ppmllok8.fsf@gmx.de> References: <5301EAE0.5080008@dancol.org> <5301EFB0.7000400@dancol.org> <87k3ctg993.fsf@gmx.de> <53021436.9080704@dancol.org> <87mwhpn5fe.fsf@gmx.de> <53022932.5010503@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392652834 5889 80.91.229.3 (17 Feb 2014 16:00:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 16:00:34 +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 17:00:42 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 1WFQcZ-0003Nz-3R for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 17:00:39 +0100 Original-Received: from localhost ([::1]:42212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFQcY-0006Pf-NR for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Feb 2014 11:00:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFQa9-00027m-9i for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 10:58:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFQa2-0005Nz-E8 for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 10:58:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFQa2-0005Nr-Bj for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 10:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WFQa2-0001El-1H for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2014 10:58: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 15:58: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.13926526614715 (code B ref 16775); Mon, 17 Feb 2014 15:58:01 +0000 Original-Received: (at 16775) by debbugs.gnu.org; 17 Feb 2014 15:57:41 +0000 Original-Received: from localhost ([127.0.0.1]:56726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFQZg-0001Dx-Ok for submit@debbugs.gnu.org; Mon, 17 Feb 2014 10:57:41 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:52269) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WFQZd-0001Dh-NU for 16775@debbugs.gnu.org; Mon, 17 Feb 2014 10:57:39 -0500 Original-Received: from detlef.gmx.de ([93.209.82.193]) by mail.gmx.com (mrgmx003) with ESMTPS (Nemesis) id 0LsCAp-1XIEas2B7X-013zg7 for <16775@debbugs.gnu.org>; Mon, 17 Feb 2014 16:57:30 +0100 In-Reply-To: <53022932.5010503@dancol.org> (Daniel Colascione's message of "Mon, 17 Feb 2014 07:22:26 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:8sZ/FMxubU5We/6TXZ+9+WK2327PkSLKZpr78N+YLMxcxCwaoA3 gXj/0hDoBRHyf2/F7crgvAZtD8rkgLrRk1HIDItURXkpthXHWMsx/vkE7UpzORFJQXLEGti KnpXGr4+U5dCviFONtGJ4lj3GlwVRYlPga9WLQEQbnuPlFBbQyhc5oOQwvVFPlUjG3VLuJC JICo2ccPGS1/WwgJpNbUQ== 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:85745 Archived-At: Daniel Colascione writes: >>> Then why was it calling dbus-check-event on the result? I checked in a >>> hack that addresses the immediate issue. >> >> Just for safety. Likely, I was not convinced the time I was writing >> this, that it couldn't be returned by read-event. Don't remember >> exactly. >> >> Does it really hurt? > > It certainly makes it more difficult to determine the intent of the code. Well, so we might throw it away (as you did with your recent patch). Thanks for this! >>> Because secrets.el was taking a whole second to load due almost >>> entirely to dbus delays. >> >> Well, that's serious. I'll check. > > I used time emacs -Q -batch --eval "(require 'secrets)". Thanks. I'll have a look on it. There are other annoyances with secrets.el on my todo, so it will be a more extensive debug session. However, I doubt we shall touch the code during the freeze. >> However, is it just secrets.el loading, or also normal operation in >> secrets.el, which are delayed > > I don't know. Secrets has other problems that I have to fix > separately. (By the way: dbus appears to hang if there's an error in a > message spec and the bus disconnects from underneath us. Try > (dbus-call-method :session "org.freedesktop.secrets" > "/org/freedesktop/secrets/collection/login" > "org.freedesktop.Secret.Collection" "SearchItems" '(:array > (:dict-entry "host" ("xxxx" "xxxx")) (:dict-entry "port" "imaps"))). A > signal of some sort pertaining to the disconnection is delivered to > xd_read_message_1, but it drops this signal on the floor, leading > dbus-call-method to loop until its timeout expires. If you want to get more traces from dbusbind.c, compile Emacs with "env MYCPPFLAGS='-DDBUS_DEBUG -Wall' make". >> We're speaking about 0.1sec delay. Does it really hurt? (Yes, I'll check >> the secrets.el case). > > Yes, 100 milliseconds is far about the threshold at which > interactivity is visibly affected. It's completely unacceptable. It's > worse when a single logical operation involves multiple dbus calls. > > No. You seem to be operating under the something interesting notion > that it's reasonable for an interactive program to simply stop > responding for 100ms. The threshold of human perception is widely > regarded to be somewhere in the 30ms neighborhood. Hmm. Problems with the dbus code were problems of being blocked, so far. Performance hasn't been on focus (yet). I agree with you that it shall be also tuned, but my focus seems to be different :-) If you have (further) tuning proposals, go on! > Right. I looked up the change history, and making dbus-call-method > async was the right choice. The event delivery, however, needs to be > refined. There's no reason, in principle, that dbus-call-method > shouldn't be able to return instantly on call completion. The code you've seen was the best compromise I could find. Of course, one could reduce the timeouts in read-event. But OTOH, D-Bus messages are not known to respond fast, in general. (This might change with the upcoming kdbus, which is implemented as zero-copy). > You misunderstand me. The code I checked in "fixes" the problem for > both the base case and the scenario I described. The code that was > there yesterday is similarly broken --- with respect to the 100ms > delay --- > for both uses. There's nothing to debug right now. Again, I wouldn't call it "broken". It was a tradeoff between response time of D-Bus calls, and the number of read-event calls. Of yourse, this depends also on the underlying machine. My main development machine is 5 years old, not so fast ... >> Definitely nothing for 24.4, we're in feature freeze. And before we're >> adding such a patch, I recommend to discuss Stefan's proposal to add >> another event queue in the main loop for such kind of special events. > > I'll have to go find that thread. I'm not sure what "another event > queue" means, exactly, or how it would help. If it's just a different > kind of accept-process-input, one that pulls only events of a certain > sort out of the kbd buffer, then it's still vulnerable to the > reentrancy problem I described in my first message. It hasn't been discussed too much. The best reference would be ; Stefan explains what's behind this idea. Best regards, Michael.