Re: dbus-call-method takes a minimum of 100ms per call?!

[Daniel Colascione]

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.