Tracking DBusWatches

[tsuraan]

> Right... with a main loop, the wakeup_main() function is supposed to
> solve this. Since there's no way to wake up read_write(), it's not
> helpful to set a wakeup function in the no-main-loop case.
>
> As you say the solution would be to add a pipe that read_write() also
> selects on. This is how g_main_context_wakeup() works with the GLib main
> loop.
>
> Hmm. Well, for now I guess any app beyond simple command line apps just
> has to use a full main loop.


Still trying to wrap my head around the problem (I'm a bit slow some days
:).  The analogue to using read_write_dispatch is to use
set_watch_functions, select'ing on the fds of any active watches, and
calling dbus_watch_handle<http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusWatch.html#gc2acdb1794450ac01a43ec4c3e07ebf7>on
any handles that have associated file descriptors that come back from
the
select.  So, the issue is that, although the callbacks registered with
set_watch_functions are modifying whatever data structure the
read_write_dispatch calls, read_write_dispatch never leaves its select, and
will thus never be aware of function calls being done.  Right?  So, in my
program I need to have the set_watch_function callbacks put a little data in
a pipe that the selecting thread is monitoring so that it refreshes the data
structure containing the watches.

As a more concrete question, does dbus_connection_send_with_reply trigger
the AddWatchFunction callback with a DBusWatch object that needs servicing
in order for the dbus function call to be initiated, or does it work some
other way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070209/2971edb5/attachment.htm