[patch] break glib bindings by adding timeout_milliseconds
hp at redhat.com
Tue Feb 28 21:31:52 PST 2006
On Tue, 2006-02-28 at 20:58 -0500, David Zeuthen wrote:
> Patch is pretty trivial and 'make check' still works (you may need to
> 'make clean' though). OK to commit?
It won't solve your problem without more work...
Two more things you'd have to change:
- in dbus-pending-call.c the timeout gets clamped to a max of 6 hours.
The comment there mentions some math that needs fixing for overflow
issues if changing this.
- the bus has a reply timeout of 5 minutes (configurable in the conf
So when testing I think you probably just were exceeding the default
timeout of 25 seconds or so when suspending, but not the 5 minutes.
Either that or the 5 minute timeout doesn't work, which is another issue
Implementation aside, I don't think an INT_MAX timeout is the right
approach. If you mean "forever" then we should just make it really be
forever, not 49 days. Kind of tricky since there's only one -1 magic
value - with dbus_connection_read_write_dispatch() it means forever,
with the pending call stuff it means "default timeout"
The 6 hour max seems kind of wrong - the 5 minutes in the bus seems more
logical, if there's going to be a max. If the user's stuff locked up and
they started getting frustrated, it might self-recover before they
tossed the computer out the window. I guess I was thinking the bus max
is both configurable and a more clearly-understood use case while the
client lib max might be used in some weird peer-to-peer situation.
Whether it's forever or 49 days, keep in mind that if you have no short
timeout you're putting your app in the hands of the remote app; if the
remote app never replies, you will be locked up for good. So don't do
this with any untrusted app. (Arguably this means it's not such a good
idea to have the "infinite timeout" API since it's something of a minor
More information about the dbus