bus limits

[Colin Walters]

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?

> I think it's likely that app authors do have to assume every message can
> get lost - that's the nature of IPC 

I don't understand - barring kernel bugs, messages over pipes, TCP
sockets, etc can't be lost.  After you write data to a pipe, and get a
success result back from the "write" call, you can be sure the app will
get the message.  I'd call them a "reliable" transport, which is what I
thought D-BUS was aiming to be?

http://freedesktop.org/Software/dbus/doc/dbus-tutorial.html
> D-BUS may happen to be useful for purposes other than the one it was 
> designed for. Its general properties that distinguish it from other
> forms of IPC are: 
[...]
>        * Stateful, reliable connections held open over time. 

What's happening here is that D-BUS is returning success from
dbus_connection_send_with_reply, but then later sending an error back?
If that's the case, it's definitely an unreliable transport, similar to
UDP.

> and one reason "network transparent"
> isn't such a good idea. However, we should certainly make errors as
> infrequent as possible, because yes people will fail to write the error
> handling code (and often it's unclear even how to do it).

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.  And if there is state involved (as there probably
is with HAL, you don't want apps to get a device removed signal before a
device added signal) they have to block on sending later messages until
the first message reaches its target.  Basically they have to implement
TCP over D-BUS's IP :)