[patch] break glib bindings by adding timeout_milliseconds

[Havoc Pennington]

Hi,

On Tue, 2006-02-28 at 20:58 -0500, David Zeuthen wrote:
>  http://bugzilla.gnome.org/show_bug.cgi?id=332888
> 
> 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 
   file)

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
if so...


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
security pitfall)

Havoc