Subject: bug#16775: closed (Re: bug#16775: dbus interacts poorly with lisp-level event loops)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 13 Dec 2016 00:16:01 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
16775: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16775
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#16775: dbus interacts poorly with lisp-level event loops
From: Glenn Morris <[email-masked]>
To: [email-masked]
Date: Mon, 12 Dec 2016 19:15:23 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

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)

Subject: dbus interacts poorly with lisp-level event loops
From: Daniel Colascione <[email-masked]>
To: bug-emacs <[email-masked]>
Date: Mon, 17 Feb 2014 03:17:04 -0800
List-Id: <debbugs-submit.debbugs.gnu.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 <[email-masked]>
To: Emacs developers <[email-masked]>

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.