--- Begin Message ---
|
Subject: |
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 <address@hidden>
To: Emacs developers <address@hidden>
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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#16775: dbus interacts poorly with lisp-level event loops |
|
Date: |
Mon, 12 Dec 2016 19:15:23 -0500 |
|
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Michael Albinus wrote:
> given that your patch has been committed, and given that there won't be
> anything else wrt your reported problem, I propose to close the
> ticket. The rewrite of the event queue for dbus and file notifications
> are a different thing, I believe.
The rest is silence.
(closing after years with no further comment)
--- End Message ---