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: trunk r116499: Improve dbus error handling; detect bus failure Date: Mon, 24 Feb 2014 00:24:35 -0800 Message-ID: <530B01C3.5010209@dancol.org> References: <87ha7ogbz8.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 1393230292 11360 80.91.229.3 (24 Feb 2014 08:24:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 08:24:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 24 09:25:01 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 1WHqqS-0007VC-K4 for ged-emacs-devel@m.gmane.org; Mon, 24 Feb 2014 09:25:00 +0100 Original-Received: from localhost ([::1]:56263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHqqS-0006UB-6G for ged-emacs-devel@m.gmane.org; Mon, 24 Feb 2014 03:25:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHqqJ-0006GE-LD for emacs-devel@gnu.org; Mon, 24 Feb 2014 03:24:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHqqA-00027h-UI for emacs-devel@gnu.org; Mon, 24 Feb 2014 03:24:51 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHqqA-00026o-KF for emacs-devel@gnu.org; Mon, 24 Feb 2014 03:24:42 -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=vk/632ytxTr5CoeFmn8jXCV0/8/K/BWcIh2F2qSs4Ok=; b=X4Kc3ZHqcp30BEQ2hu4fIDNweBEOKJy8V/tlLhU/ZI+B9ZbNN0YWtL8KzTrrU7oPyexSc2lSbg+xyvHtNNnGgLlAyh4+BqcFTQ2O9vvawSTLlEu1xhHsH5NfXcs39EfGV0xprfPOryatUrIebdm9QJqmaVWow8g1ciUkwRftYGxQA4rOxg1/L5GpU6m3wZaN2ZuPsdGdpLHg5+TD78pN5ETZliGClpWILKAw7rAPtd4kqUsMFmKl4ylqQ3zEQ7K6ZqRF0cINcxzlEjUW3wgB5YVg2LAfcrJigViXGrml02GxYwQ8OshVDbNMgouj9RzjfyRexS0fcTsXaXDPxBPqJQ==; 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_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1WHqq4-00014h-3J; Mon, 24 Feb 2014 00:24:36 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: <87ha7ogbz8.fsf@gmx.de> 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:169827 Archived-At: This change is a bug fix --- a non-trivial bug fix, but a bug fix. There's no contractual behavior change. On 02/24/2014 12:18 AM, Michael Albinus wrote: > Daniel Colascione writes: > >> + (dbus-handle-bus-disconnect): New function. React to bus >> + disconnection signal by synthesizing dbus error for each >> + pending synchronous or asynchronous call. > > This is a new functionality. Why do you want to add it during feature > freeze? And what is the reasoning behind? When a D-Bus bus disconnects, > there might be more serious problems but pending method calls. And you would propose to just ignore bus disconnects? Sending an error is the best we can do. > Is it about performance, and abortion of such pending calls? When does > it happen, that a bus disconnect for you? It's not about performance, but since I had to restructure the code to handle errors anyway, I used a mechanism that doesn't involve so many hash table lookups. > >> + (dbus-notice-synchronous-call-errors): New function. >> + (dbus-handle-event): Raise errors directly only when `dbus-debug' >> + is true, not all the time. > > Why that? You cannot assume that `dbus-event-error-functions' is non-nil > (and contains `dbus-notice-synchronous-call-errors'). We still call dbus-event-error-functions. In fact, that's how error propagation to synchronous calls works now. > I still don't see what you are trying to resolve. Lisp errors are shown > when happening in handlers, what else do you want to achieve? As usual a > typical use case would help. First of all, before my change, the dbus could would just hang in response to bus disconnects. Now calls terminate immediately with a reasonable error. dbus disconnects the bus on certain usage errors. Here is a call that results in an immediate bus disconnect: (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"))) Additionally, I strongly dislike signaling errors from the read-event handler: doing that makes it easy to "leak" errors up to unrelated outer dbus calls. Please carefully consider cases where more than one dbus call might be pending on the stack at a time. > And *if* you are applying such changes, I would expect respective doc > changes, for example explainig the (changed) structure of the values in > `dbus-return-values-table', or mentioning > `dbus-notice-synchronous-call-errors' and its intended use in dbus.texi. Neither of these symbols is public. The contractual behavior has not changed.