On Sun, Jun 01, 2008 at 09:14:37AM -0400, Dan Williams wrote:
Suddenly all the state dependent on a D-Bus service is suspect,
because
you have no idea what's going on while the bus is down. You have to
re-synchronize your state after the bus comes back, and that's not a
simple task.
No. This is a myth.
It is *desirable* to resynchronize state. Dbus clients come and go and get
restarted (or do you want to argue the farcical 'any dbus connected
service cannot be restarted' in which case have a spade and keep digging)
> - Why isn't there a recovery mechanism
The recovery mechanism would be in each service, because the service
knows whether or not it needs recovery or not, and would know how to
merge/synchronize it's state with the services that it depends on. Some
don't need to. But ones with state dependent on other D-Bus services
would.
For 99% of cases if dbus sent a 'dbus restart' message (or the dbus library
did that) then application behaviour would be acceptable but not ideal if
- Applications ignored it
- Some applications just restarted themselves from scratch
Almost no work required
it's communication channels with the daemons that affect that
NM-specific state are gone, and NM can't make any assumptions about
what's happening in any other daemon while the bus is gone. Maybe your
VPN just came up for rekeying, but the signal got lost because D-Bus
isn't around. So when the bus comes back, your VPN connection is
already dropped.
Which is fine. In a proper model NM takes a "dbus exploded" message from
the support library and either restarts itself or reconfigures.
> "oh dear it broke everyone reboot" is not good
engineering.
In some cases, it's a cost/benefit analysis. Is the cost of writing and
maintaining a pile of code that handles a D-Bus restart, which shouldn't
ever happen, worth the benefit? In some cases, definitely. In other
cases, probably not. That isn't an excuse to write crappy software, but
it's certainly not as simple of a problem as you present it.
For the complex cases like changing nautilus icons agreed but for the 99%
case the 'I missed it' and 'restart' responses are both better than
praying
it doesn't occur.
Another approach of course would be to hang a persistant state daemon off
dbus which is the way a lot of object models actually work and which can
answer "last state of X was" - that also helps sort out a pile of runtime
ordering issues.
Alan