bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Daniel Colascione
Subject: bug#16775: dbus interacts poorly with lisp-level event loops
Date: Mon, 17 Feb 2014 03:17:04 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0




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









reply via email to

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