strange D-Bus interactions with gtk_dialog_run

[Havoc Pennington]

Hi,

The big picture is that if you call dbus_connection_setup_with_g_main() 
(this will get called if you're using dbus-glib), then there will be 
handlers in the GLib main loop that do the read, write, and dispatch.

If you also have your own thread doing read, write, and dispatch 
(pop_message is just another flavor of dispatching), then you have two 
different threads (main loop thread and your thread) both trying to grab 
messages. Only one of them is going to get each message. The result is 
total chaos - you have no idea if a given thread will get a given message.

So, the solution is fairly simple: don't do this.

If you set up the DBusConnection with the GLib main loop, then don't use 
the other thread. Instead, add a handler to the DBusConnection, and let 
the main loop invoke your handler. You don't want to block in the main 
thread since all blocking should be done by the main loop.

Or if you want to use your thread, then don't set up the connection with 
the GLib main loop.

It does not make sense to have two threads both trying to grab messages 
in a free-for-all, in short.

There is no magic here; it's very simple conceptually. There's an 
incoming list of messages. dispatch() means to pop one off, run the 
handlers registered with the connection (passing them the message), then 
drop the message. pop_message() means to pop one off (then you do what 
you want with it).

read_write() means to read from the socket, appending any messages read 
to the incoming list.

If you register a DBusConnection with the GLib main loop, the main loop 
will invoke handlers that read_write() when the socket has data to read, 
and that dispatch() when there is stuff in the incoming list of messages.

Havoc