strange D-Bus interactions with gtk_dialog_run

Gnaural gnaural at users.sourceforge.net
Mon Nov 19 10:41:12 PST 2007


Hi, and thanks -

--- Havoc Pennington <hp at redhat.com> wrote:
[...]
> 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.

I really appreciate your reply. I think my answer is
"yes, I am using main loop integration." And so I
guess I'm doing a "no-no" by using
dbus_connection_read_write_dispatch with
dbus_connection_pop_message.

Given all you say, what I'm seeing is almost surely
because of my own incorrect D-Bus implementation. So
rather than flooding this post with lots of debugging
info, maybe it is better if I just ask, in a few lines
of pseudo code, "what would be the right way to do
this?":

///////
 while (0 != dbus_connection_read_write (bus, -1))
 {
 if (NULL != (msg = dbus_connection_pop_message
(bus)))
  {
   if (dbus_message_is_method_call (msg,
"org.gnaural.interface", "GetMyMethod")) 
     GetMyMethod (msg, bus);
   dbus_message_unref (msg);
  }
 }
///////


Basically, I just want that loop to sit "forever" in
the main app to wait for any client apps to call a
method (which merely offers the value of a double).
I'm using the low-level C API simply because the D-Bus
code cross-compiles to Win32 so easily (BTW, the Win32
version appears to work). And I started with Matthew
Johnson's example code because it did everything I
needed in a couple dozen lines of code. The only
problem was that his example is non-blocking. I
preferred blocking or callbacks. Callbacks would be
lovely, but the faster/simpler solution seemed to just
be replacing "0" with "-1" in the
dbus_connection_read_write call, then launch it in a
thread and forget about it.

But the code above didn't work, never getting past
dbus_connection_read_write (because I hadn't flushed
the queue maybe?). meanwhile,
dbus_connection_read_write_dispatch looked like it
worked great (maybe because it was flushing by
"dispatching to nowhere"?)-- but as we know had
unpredicatable/unacceptable side effects in the Linux
version.

Again, thanks for any tips you can offer!


More information about the dbus mailing list