Pending reply timeout(Without glib)

[Havoc Pennington]

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
> timeouts?

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.

Havoc