strange D-Bus interactions with gtk_dialog_run

[Havoc Pennington]

Hi,

Gnaural wrote:
> The example code is non-blocking, using
> dbus_connection_read_write(conn, 0). Which wasn't
> really what I wanted anyway, so I went ahead and
> implemented a blocking approach, by spawning a gthread
> that starts a loop along these lines:
>  while (dbus_connection_read_write_dispatch
> (gds_remote_connection, -1)) { }
> approach
...
> BTW, does this thread in any way relate?:
> http://lists.freedesktop.org/archives/dbus/2005-April/002480.html

Are you using the GLib main loop integration (or other main loop 
integration)? The thread there is about a problem with the main loop 
integration and recursive loops; I don't know if the fix discussed in 
that thread was ever committed to dbus-glib. If it was not, and you are 
using the main loop integration, then you may well see that problem.

If you are not using the main loop integration, that thread won't apply.

If you are using the main loop integration, though, it does not make 
sense to have another thread doing read_write_dispatch(); the results of 
dispatching yourself, and also having the main loop dispatching, will be 
unpredictable and definitely not good.

In sum, if you are using the main loop integration:
  - be sure you do not also try to read_write_dispatch() in your own
    loop in another thread
  - be sure the fix mentioned in the link above was applied

If you are not using main loop integration:
  - I don't see how gtk_dialog_run() could get involved at all with dbus

In both cases:
  - be sure you init threads both for GLib and for dbus
    g_threads_init(), dbus_threads_init_default()
  - it would be helpful to post a backtrace, with debug symbols,
    when the program is deadlocked
  - it will be tough for anyone to help debug without a small,
    easily-compilable test case. (i.e. attach a single .c file,
    and the command line that compiles it)

Havoc