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