Method calls without timeouts

[Havoc Pennington]

Hi,

To be clear, I was just giving background - I was not reviewing the
patch or saying it was bad. Still needs someone to review. I glanced
quickly and it looked fine, but I didn't do any kind of diligence.

On Tue, Jul 22, 2008 at 2:15 PM, Scott James Remnant
<scott at canonical.com> wrote:
> I could find no evidence of any code to limit the maximum number of
> expected reply records, which is a shame, because this is the right way
> to limit resources.

The code is in connection.c:bus_connections_expect_reply()

"man dbus-daemon" documents the setting, which is max_replies_per_connection

Note that with no timeouts on replies, a connection can wedge itself
by reaching this limit ... but we can just say "don't do that then" I
guess. The default is 1024*8, so it would only be reached in case of a
bug anyhow surely. Nobody will have that many pending replies on
purpose unless their design is just not appropriate.

> The timeout here is bizarre, because it clamps all bus method calls to a
> maximum of 5 minutes, even when the client has given a longer timeout.

Sure, I agree with this from a user-expectations point of view (though
it is not different from Apache having a server-side timeout that is
unrelated to a web browser having a client-side timeout, so it should
not be _that_ shocking once one thinks about it)

> There's a meme going around that this is the wrong way to do such calls,
> and instead one should return immediately and emit a signal to indicate
> completion.
>
> This is hideous for a number of reasons, notably:

Agreed

Havoc