Pending reply timeout(Without glib)
hp at redhat.com
Thu Jun 29 08:50:39 PDT 2006
Claudio Takahasi wrote:
> Some questions:
> 1. Besides the send with reply, which situations a new DBusTimeout is
> created/used? When it can be toggled(we don't have threads)?
The API does not define when it will be used... it can be used any time
libdbus needs a timeout. The toggling can likewise happen at any time.
I think currently it's only for send with reply, but I'm not sure. You
would have to look at the source code.
> 2. Is it correct call the dbus_connection_dispatch inside the timeout
> callback function to dispatch messages(eg: NoReply error message)?
It is not incorrect, but it is dangerous. This produces "reentrancy"
(running arbitrary dispatch handlers) in situations where it might cause
confusing bugs to happen.
> 3. Another possiblity is use dbus_connection_set_dispatch_status.
> However, according to D-Bus documentation, DBusDispatchStatusFunction
> should simply save an indication that messages should be dispatched
> later(when the main loop is re-entered).
This is advice rather than a rule. The dbus callbacks that add/remove
timeouts, watches, update dispatch status, etc. have to be called in a
lot of different situations. It's somewhat
dangerous/potentially-confusing to try to dispatch in all these
situations; the program will be a lot more robust if you always just
dispatch in one place.
> Therefore, use
> dbus_connection_set_dispatch_status_function doesn't help because it's
> not allowed call dbus_connection_dispatch due to reentrancy and
> because our main loop still blocked while there is not data for watch
> fd or other bluetooth fds. Is there another possible design to handle
If your main loop does not support timeouts on the select(), I don't
think there's much you can do without threads... it's going to block
until there's IO, and no timeout can fire.
More information about the dbus