Method calls without timeouts

[Havoc Pennington]

Hi,

On Fri, Jul 18, 2008 at 12:22 PM, Thiago Macieira <thiago at kde.org> wrote:
> Second, I am not sure this is entirely a good thing. I know the bus daemon
> had a reason to have this upper limit, but I really don't remember now.
> Can someone remind us?
>
> In any case, what happens if applications start using very high timeouts
> and no replies come? Won't that start eating up resources on the bus
> daemon?
>
> Shouldn't we simply add a marker in the message headers saying that no
> timeout handling by the bus daemon is necessary?
>

Remember there are multiple timeouts, the background on each -

The timeout on the client side (in DBusConnection/PendingCall) is
intended to keep the client from blocking indefinitely if the other
end is dead. This timeout applies with a bus daemon, or with a direct
connection to another app with no daemon. This timeout can be thought
of as the max time the user will wait for an error message if there's
a deadlock or the other end of the connection is wedged. So by default
it should probably be short enough to give an error message before
someone forgets what they clicked on, but long enough never to happen
unless things are genuinely broken. For long-running operations, a
client could manually make it longer for a particular call. The
timeout here is analogous to the timeout a web browser would put on an
HTTP request.

The timeout in the bus daemon is because the bus daemon allocates
resources for each expected method call reply. The resources are a
record to track whether the reply is in fact allowed (only expected
replies are allowed on system bus). Because, like the kernel, the
system bus is not supposed to allow clients to allocate infinite
resources, each "expected reply" record has a finite lifetime
(timeout), and there's also a max number of expected reply records.

Havoc