search

alphapapa / ement.el

A Matrix client for GNU Emacs
GNU General Public License v3.0
506 stars 45 forks source link

dbus-ping takes ~25s to finish evaluating #98

Closed 9viz closed 2 years ago

9viz commented 2 years ago

dbus-ping call in ement-notify takes ~25s in my laptop to finish evaluating. In the meanwhile, Emacs is locked out and I cannot do anything :(

(benchmark-run 1 (dbus-ping :session "org.freedesktop.Notifications")) returns (25.001071378 0 0.0).

alphapapa commented 2 years ago

Is that a bug in this package, a bug in dbus-ping, a bug in your laptop's configuration, or...? I don't know anything about your laptop and what software you have on it. It doesn't cause that problem on my system, and evidently not on @tsdh's either (pinging you, Tassilo, since that patch was from you, so maybe you'll know something about it).

tsdh commented 2 years ago

Nope, obviously it never occurred to me. @vizs, please do M-x toggle-debug-on-quit RET and then M-e (ement-notify-dbus-p) RET. When emacs then hangs for some seconds, hit C-g which will give you a backtrace buffer which you can post here. In the backtrace buffer you can type c to continue. Wait again a few secs and C-g again to check if emacs is still hanging in the same call stack, etc.

9viz commented 2 years ago

20 Sept 2022, 12:32 by @.***:

Nope, obviously it never occurred to me. > @vizs https://github.com/vizs> , please do > M-x toggle-debug-on-quit RET> and then > M-e (ement-notify-dbus-p) RET> . When emacs then hangs for some seconds, hit > C-g> which will give you a backtrace buffer which you can post here. In the backtrace buffer you can type > c> to continue. Wait again a few secs and > C-g> again to check if emacs is still hanging in the same call stack, etc.

Debugger entered--Lisp error: (quit)   dbus-call-method(:session "org.freedesktop.Notifications" "/org/freedesktop/DBus" "org.freedesktop.DBus.Peer" "Ping")   dbus-ping(:session "org.freedesktop.Notifications")   (progn (dbus-ping :session "org.freedesktop.Notifications"))   eval((progn (dbus-ping :session "org.freedesktop.Notifications")) t)   elisp--eval-last-sexp(nil)   eval-last-sexp(nil)   eros-eval-last-sexp(nil)   funcall-interactively(eros-eval-last-sexp nil)   call-interactively(eros-eval-last-sexp nil nil)   command-execute(eros-eval-last-sexp)

on both times.

I'm using awesomewm here and the dbus stuff should be the default.  I'm on master  "cd2168cd131852279a7d9257c7dff45224c9d6a9".  [ Sorry about not including the info in the OP, I'm so used to M-x report-emacs-bug doing it for me that I forget.  :( ]

OTOH, do we really need to ping the notification dbus thingy?  If the user has a dbus session but does not have a notification daemon running, then they are likely to be using a window manager and hence probably do not have a daemon running intentionally. <--- I was this guy, I only started using the dbus interface for notifications because awesome supported it OOTB, otherwise I just spawned a lemonbar for the notifications I cared.

tsdh commented 2 years ago

@vizs Thanks. I'm not sure about the question if pinging is needed. I assume (dbus-ping :session "org.freedesktop.Notifications") returns nil for you after the standard timeout of 25000 milliseconds, right? If so, I'd suggest @alphapapa simply uses the TIMEOUT parameter of dbus-ping in the call with a reasonably low value. I get t as the result even when I use a value of 1 (ms), so it seems like a short timeout of say, 500 ms, would be a good compromise.

9viz commented 2 years ago

20 Sept 2022, 13:43 by @.***:

@vizs https://github.com/vizs> Thanks. I'm not sure about the question if pinging is needed. I assume > (dbus-ping :session "org.freedesktop.Notifications")> returns > nil> for you after the standard timeout of 25000 milliseconds, right?

Yes.  It returns nil after 25s.