Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flood of dbus messages bogs down mowedline #22

Open
retroj opened this issue Nov 25, 2016 · 0 comments
Open

flood of dbus messages bogs down mowedline #22

retroj opened this issue Nov 25, 2016 · 0 comments
Labels

Comments

@retroj
Copy link
Owner

retroj commented Nov 25, 2016

While a flood of dbus messages will always bog the program down to a certain degree, the way that mowedline's dbus loop works worsens the situation.

(define (dbus-eventloop)
  (dbus:poll-for-message)
  (thread-sleep! 0.01)
  (dbus-eventloop))

The thread-sleep call in the above is necessary to keep mowedline from consuming 100% cpu, but that hard-coded duration also means that a minimum of a hundredth of a second will be spent processing any dbus message.

The situation in which I encountered this is as follows. I'm using the tiling window manager xmonad, with its logHook configured to update mowedline over dbus. A badly behaving program (KeePass2 running on mono) constantly tries to resize its own window (because xmonad is not a reparenting wm, and this confuses mono). This causes logHook to be triggered for every resize event, so mowedline gets flooded with dbus messages. xmonad itself remains responsive, but mowedline lags by seconds or minutes, or sometimes crashes, with the flood of messages.

If we could replace that call to dbus:poll-for-message with a hypothetical dbus:wait-for-message that would use something like thread-wait-for-i/o!, then the hard-coded sleep duration could be eliminated, and this problem with floods from dbus would be reduced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant