bus limits

[Colin Walters]

On Sun, 2004-08-15 at 13:16 -0400, Havoc Pennington wrote:
> On Sun, 2004-08-15 at 12:58, Colin Walters wrote:
> > On Sun, 2004-08-15 at 12:35 -0400, Havoc Pennington wrote:
> > 
> > > One approach might be to just stop reading new messages from a
> > > connection when a limit is reached, though that could lead to deadlocks
> > > so has its own dangers.
> > 
> > Deadlocks in the application or in dbus?
> > 
> 
> In the app, e.g. the app is blocking waiting for some other message
> before it processes the pending replies, or whatever.

Yeah, that does seem like the wrong thing then.

> D-BUS is reliable in that you will get either an error or the message
> will go through, but the other app can still crash or exit, 

When discussing transport reliablity we should assume that there are no
bugs in the apps involved.  D-BUS can't solve the problem of buggy
apps :)

> or (in the
> TCP case) the network can go down, or you can run out of memory.

Right, in those scenarios you are guaranteed to either get a successful
result or an error message from TCP, since the issue was at its level.

> > I think to handle this, if applications want to ensure the target sees a
> > message, that means they have to keep messages around until they get a
> > positive reply back.
> 
> Right, so to avoid that we'd have to have "block when the pipe is full"
> instead of "error when the pipe is full" semantics for the bus limits.
> We can certainly try to implement that. The bus limits thing just
> defines "pipe is full" for us.

Ok, that makes a lot of sense.

> The issue here is basically whether to block or EAGAIN when limits are
> reached.

Probably this is something that should be left up to applications,
similar to how you can set O_NONBLOCK on sockets.  For some
applications, there may be no state between messages, so they won't care
if the connection is full, and can just let earlier messages get dropped
on the floor.  For example a game could be sending a PlayerPosition
message.

But the default for dbus_connection_send_with_reply_and_block should
probably be to block while the queue is full, similar to how writes on a
socket block by default when the transmission window is full.

> If someone wants to try coding this, it should be fairly simple; you
> just need to not read any more data from a DBusConnection while that
> connection is at a max limit. I guess it should be OK to _write_ data
> to the connection? If so that would help with the deadlock thing.

I'm not sure I understand - isn't the problem that the bus is refusing
to make more outgoing method calls because they would require pending
replies?  So in that case we have to block on writing to the connection,
not reading from it?