dbus Digest, Vol 56, Issue 12

[Patrick Allison]

> Couldn't this patch cause messages to get delayed until a subsequent
> message comes in?  If we return from the watch in main thread #1
> without doing anything, then the thread #2 finds its reply and handles
> it, thread #1 will not process the queue again until another message
> comes in and triggers the watch again, correct?

As Michael pointed out, the new case that this patch adds doesn't cause
a problem because the watch that triggered the entry into
_dbus_connection_handle_watch stays enabled so the mainloop will spin
around again and just try to handle it again.

The case where a message gets delayed until a subsequent message comes
in happens in the reverse case - when thread #2 attempts to acquire the
I/O path via a nominally non-blocking call (say via
dbus_connection_send) that's being held when thread #1 is handling a
watch. In that case, because dbus_connection_send attempts to acquire
the I/O path without blocking, it returns immediately, no watch gets
set, and the message sits there waiting until the next message comes in
(bug #23584).

Same basic issue, though, of how to handle the case when the I/O path is
not acquirable. dbus_handle_watch was blocking to acquire it and
probably shouldn't've, and dbus_connection_send is not blocking and
probably should.

Patrick