[ CC'ing dbus list as this discussion is important for writers of D-BUS applications and for packagers ] On Mon, 2005-03-14 at 23:49 +0100, Tom Parker wrote: > I'd disagree. Yes, it'll be a pain in the ass to get right, and yup this > ain't exactly going to be the most tested code path. I'm certain your posted code is full of races and problems; you just set the connection to NULL, but NetworkManager has a number of threads and idle handlers which are not expecting it to be NULL. Some of the code has g_return_if_fail (connection != NULL), but at best you get lots and lots of error spew, and at worst NetworkManager segfaults. These failure modes are a lot worse than simply running an old instance, reliably. > However, I don't > think that restarting D-BUS should be counted as anywhere even close to > being like a new kernel. The kernel has a lot of jobs, but really it comes down to two things: 1) Drivers for hardware 2) Providing the required locking for inter-process communication, via the filesystem or sockets, etc. D-BUS is exactly like 2. > Heck, I'd rather if we didn't have to restart > for new kernels (hello kexec...), kexec is just a faster way of rebooting (hence the name "exec" which implies resetting state); it doesn't magically upgrade you to a newer kernel while it's running. > and I certainly can't see any reason > why we should restart for D-BUS. Because it's too hard, and creates user expectations which will ultimately not be met. > Especially as despite the fact that > more and more other tools are starting to become reliant on D-BUS, it > should still just be treated as just another service. But the difference with D-BUS is that it provides reliable communication semantics between those services. If the bus can go away arbitrarily, you lose that. > Even if it's just > on desktop machines, it's still very annoying when you have to restart > your machine to install something, as opposed to a few seconds of > downtime while the old version is removed and the new version brought up. No one is suggesting you have to reboot to install something. Windows doesn't require that either. I'm just suggesting that for a few critical packages such as dbus and NetworkManager, you don't get the new functionality or security update until you reboot. > Given that D-BUS will occasionally (weeks, months) get restarted, we > have 3 choices The system bus will be restarted on reboot, however often that happens. For my personal system that's several times a day, as apm and acpi are broken on my laptop. > 1) [...] > 2) [...] > 3) [...] The alternative I am suggesting is: 0) Assume the bus never goes away, and make sure distributors don't restart dbus or NetworkManager in package upgrade scripts > My 2p. I think restarts of a whole system should be avoided, and that > graceful degradation is the way to go. I agree they should be avoided, but I would much rather have a system that works 100% reliably on upgrades but requires occasional fast reboots (and we could do plenty to optimize it) for a few packages, instead of a system which works 75% of the time but the other 25% causes random hard-to-debug application crashes and eventually requires a reboot anyways to sort out. For people on the dbus list, the initial thread is here: http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00022.html
Attachment:
signature.asc
Description: This is a digitally signed message part