bus limits

[Havoc Pennington]

On Sun, 2004-08-15 at 17:43, Havoc Pennington wrote:
> 
> It'd be worth thinking about approaches other than shutting down app A
> in this case. One might be to expire the timeout on the oldest pending
> request for app B.
> 
> Of course, this still sends an error to app A saying that a method call
> on app B failed... which is the whole problem we were trying to solve
> ;-)

And this shows that if the problem is app B not responding, you're going
to potentially get a timeout because it really timed out, limits or no
limits.

The only way to say "there's no possible way to get EAGAIN" is to allow
blocking infinitely it looks like, which means you can always get locked
up by having any one of the apps you're talking to lock up. We can't
block app A with respect to only one app, since we have to read messages
from app A in order, and would have to queue infinite data intended for
app B in order to get to the data intended for other apps.

I can certainly imagine that app A is shut down because app B is not
responding, then everyone talking to app A gets shut down... sounds like
a locked-up system/desktop to me... maybe a glitch or two in one aspect
would be better.

Hmm, one detail of the current implementation is that if you set "no
reply expected" on your outgoing method call (which may make sense if it
has no return value) then the pending replies limit doesn't get
involved, since the bus doesn't have to track for a timeout reply. And
the message is still guaranteed to be sent unless the bus runs out of
memory, reaches some other limit, or app B crashes.

I don't see a silver bullet here guys... tempted to stick with the
kernel/X model, since that's served D-BUS well so far. Just crank up the
limits nice and high, and say yes, if you want to be sure a message was
received you have to process the ack reply (or the error).

After all, we still don't know even the 32-pending-reply limit will be
reached in practice when there aren't bugs involved.

Another possible tweak I just thought of: play "scheduler" games, e.g.
when an app has a lot of pending replies, be sure to process messages
sent to that app before messages sent from that app.

Havoc