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: dbus-call-method takes a minimum of 100ms per call?! Date: Mon, 17 Feb 2014 02:56:32 -0800 Message-ID: <5301EAE0.5080008@dancol.org> References: <53019AE7.9050504@dancol.org> 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 1392634602 12648 80.91.229.3 (17 Feb 2014 10:56:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 10:56:42 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 17 11:56: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 1WFLsY-0007AX-0f for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 11:56:50 +0100 Original-Received: from localhost ([::1]:39062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFLsX-0007Ti-Nl for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 05:56:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFLsP-0007Sh-LG for emacs-devel@gnu.org; Mon, 17 Feb 2014 05:56:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFLsJ-000881-Fn for emacs-devel@gnu.org; Mon, 17 Feb 2014 05:56:41 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFLsJ-00087r-2i for emacs-devel@gnu.org; Mon, 17 Feb 2014 05:56:35 -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:To:MIME-Version:From:Date:Message-ID; bh=PfZeKlb1OQ4Dv8kByp3h+TWsPlkztqqAGZ6WL6FlvD0=; b=d+LGuo81vs9Dz/2okuN4vs3WXZPynXEaRxezrXZHnfg1VRkwvevETg9Lwgf83YkmTh10Nu3k1T7Iz0YZe0kQ/0fnk6OriGKF8/AU72hOrUfzaxfKZJ2V6pZ8MQITvU8Ts3DiS4uwjOg1RgQ4dGGdeLxxOJg88/zOPsz8Mqp9t7OcBeyUx3ZvKHwAdUBBndbAwU8tVeJJVthYDZN1H3vqHmOmsoyzTJqGCcFkiKvnC1ez3Kxr4heq8ZFa6E87NHinBW3suBbioKtyOTZW9U5HQmGd42ODRY3CYR6rW/3YPpPeEVeTERDIpOg4mVOLRFQm9v2xqoJV4CnX84M4mqSLQA==; 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 1WFLsI-0007at-10 for emacs-devel@gnu.org; Mon, 17 Feb 2014 02:56:34 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <53019AE7.9050504@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:169689 Archived-At: On 02/16/2014 09:15 PM, Daniel Colascione wrote: > I think we're supposed to exit as soon as we get a dbus event and > short-circuit the timeout, but no such event seems to get delivered, > even for successful calls. I can dig a bit into dbusbind.c, but I'm no > dbus expert. 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. 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. The immediate problem is that read-event never actually returns because the dbus event is special --- 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. 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.