D-Bus upgrade problems in Debian

Thiago Macieira thiago at kde.org
Sat Aug 30 10:40:06 PDT 2008


Havoc Pennington wrote:
>If you have a situation with a large number N of rarely-tested and
>complex codepaths maintained in multiple packages by different people,
>then reality is that at any given moment in the lifetime of a Linux
>distribution one of those codepaths will not work. Restarting dbus,
>however, _requires_ that _all_ of them work _always_.

I'll throw another wrench in the gears.

Not only must all applications always survive a restart gracefully, they 
must do so in the proper order or be able to gracefully deal with the 
condition tha the service they were talking to isn't present yet.

Imagine the following very simple and yet very likely case:
- you have one service running, HAL
- you have one single application running, which uses HAL
- D-Bus restarts
- both applications gracefully handle the socket closing, then reopen a 
connection, re-request their names, if required

Here's the catch: due to the purely asynchronous nature of the thing, the 
application connected to D-Bus first and made a call to HAL, which hasn't 
yet requested its name org.freedesktop.hal. What should the application 
conclude?

In this case, the solution is for the application to go back to sleep and 
re-try in a few seconds. And again and again.

Remember: each application must do that. Every single interprocess 
dependency will have to be dealt with like that.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080830/a37785b5/attachment.pgp 


More information about the dbus mailing list