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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
