bus limits

Havoc Pennington hp at redhat.com
Sun Aug 15 16:50:02 PDT 2004


On Sun, 2004-08-15 at 18:11, David Zeuthen wrote:
> 
> One way to get around this would be to enforce the limits per
> connection-pair instead. E.g. in your example the bus blocks on messages
> from A to B, but not A to C.

That doesn't help, because you have to read data from A in order - if
messages to B are mixed in, then you have to read them in order to get
at messages to C. So if B were blocking you'd read potentially infinite
data for B and keep it around, circumventing any attempt at a limit on
how much data the A-B pair could be responsible for.

> Ideally it should also be possible to specify limits per service.
>  E.g.
> so even though app A is blocked for some reason, it will always receive
> e.g. a signal if it comes from a service that specifies "ignore all
> limits" (such as from the kernel that says it's overheating; e.g. a
> policy piece needs to take action immediately). Even, if assuming limits
> per connection-pair and your example, when that service is owned by app
> B.

Some type of "message priorities" helps, but only as long as you're
still reading messages from the app... you have to read the messages off
the pipe in order, and that means memory allocation for the message
buffer.

Havoc




More information about the dbus mailing list