[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r116499: Improve dbus error handling; detect bus failure

From: Michael Albinus
Subject: Re: trunk r116499: Improve dbus error handling; detect bus failure
Date: Mon, 24 Feb 2014 09:54:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Daniel Colascione <address@hidden> writes:

>>> +   (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.

Yes, but you also silently assume that `dbus-notice-synchronous-call-errors'
is called from there ...

> 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")))

Wow, this is really strange. It's not obvious to me whether this is a
D-Bus bug, or whether this is intended by the "org.freedesktop.secrets"
daemon. Anyway, you are right, this must be catched.

>> 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.

You have added `dbus-notice-synchronous-call-errors' to
`dbus-event-error-functions'. This is a public change, and it deserves

Furthermore, I had developers in mind when I've asked for doc
enhancement. Even I, as the original writer of the code, need to consult
the doc strings for hash table structures and alike. It would ease our
life, if the doc is up-to-date and reasonable.

Best regards, Michael.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]