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

[Daniel Colascione <dancol@dancol.org>]

-------- Original Message --------
Subject: Re: dbus-call-method takes a minimum of 100ms per call?!
Date: Mon, 17 Feb 2014 02:56:32 -0800
From: Daniel Colascione <dancol@dancol.org>
To: Emacs developers <emacs-devel@gnu.org>

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.