[Top][All Lists]

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

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

From: Daniel Colascione
Subject: Re: dbus-call-method takes a minimum of 100ms per call?!
Date: Mon, 17 Feb 2014 02:56:32 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.

reply via email to

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