bug#16775: dbus interacts poorly with lisp-level event loops

[Michael Albinus <michael.albinus@gmx.de>]

Daniel Colascione <dancol@dancol.org> 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. 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).

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

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

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

Best regards, Michael.