flood of dbus messages bogs down mowedline

[retroj]

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.