From: Daniel Colascione <dancol@dancol.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 16775@debbugs.gnu.org
Subject: bug#16775: dbus interacts poorly with lisp-level event loops
Date: Mon, 17 Feb 2014 05:52:54 -0800 [thread overview]
Message-ID: <53021436.9080704@dancol.org> (raw)
In-Reply-To: <87k3ctg993.fsf@gmx.de>
On 02/17/2014 05:27 AM, Michael Albinus wrote:
> Daniel Colascione <dancol@dancol.org> writes:
>
>> 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.
>
> dbus-call-method does not expect the D-Bus event to be returned by
> read-event.
Then why was it calling dbus-check-event on the result? I checked in a
hack that addresses the immediate issue.
> It simply calls read-event in order to trigger event
> handling. The loop itself checks, whether the respective event has been
> inserted into dbus-return-values-table. And when *other* but D-Bus events
> do arrive in the meantime, they must be preserved in unread-command-events.
>
> Why is it a problem to wait at least 100ms? D-Bus messages are not
> expected to perform in real time (whatever this means).
Because secrets.el was taking a whole second to load due almost entirely
to dbus delays.
>> 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.
>
> Why do you want to terminate non-locally in dbus-call-method? If you
> need asynchronous behaviour, there is dbus-call-method-asynchronously.
The goal is to make dbus-call-method return as soon as the method call
is complete.
>> The immediate problem is that read-event never actually returns because
>> the dbus event is special
>
> As said above this is not a problem but intended.
I find it hard to believe that the overall effects were intentional.
Randomly delaying all of Emacs because something tried to make a dbus
call is completely unacceptable.
>> --- 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.
>
> I don't understand the scenario. Could you, please, give a code example?
No, because the current code is so broken that any example I gave
wouldn't actually demonstrate the problem I'm trying to explain above:
I wasn't expecting the desirability of random 100ms delays to be a point
of debate, so I jumped right to the problems one might encounter with
various solutions. You can trigger the scenario I'm worried about by
performing a dbus call in an X drag-and-drop handler while somebody else
is already blocked waiting for a dbus call.
>> 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.
>
> There is already the discussion that such events (dbus, file
> notification) should be implemented differently. I don't know whether
> this shall be done as process type or as a separate queue to be checked for.
I have a partial patch that implements this scheme: add another argument
early-return to Fread-event and sit-for. early-return can either be nil
for present behavior or a function of no arguments. Plumb early-return
all the way down to wait_reading_process_output, and have that function
call early-return just before running xg_select. If early-return returns
true, abort the select loop and return nil from Fread-event. This way,
you could pass into read-event in dbus.el an early-return function that
checked for the existence of the return value on
dbus-return-values-table. Then, the function would return immediately on
a dbus call being complete no matter how deeply the calls were nested.
The mechanism could also take over the role of the current wait_for_cell
stuff.
next prev parent reply other threads:[~2014-02-17 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5301EAE0.5080008@dancol.org>
2014-02-17 11:17 ` bug#16775: dbus interacts poorly with lisp-level event loops Daniel Colascione
2014-02-17 13:27 ` Michael Albinus
2014-02-17 13:52 ` Daniel Colascione [this message]
2014-02-17 15:07 ` Michael Albinus
2014-02-17 15:22 ` Daniel Colascione
2014-02-17 15:57 ` Michael Albinus
2014-03-26 13:10 ` Michael Albinus
2016-12-13 0:15 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53021436.9080704@dancol.org \
--to=dancol@dancol.org \
--cc=16775@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).