Hey, On Fri, Feb 25, 2011 at 2:28 PM, Havoc Pennington <h...@pobox.com> wrote: > So upstream's advice is, don't restart, because apps won't handle it. > > If you want to fix all the apps, you can do so. There are no > dbus-daemon changes required.
If you really wanted to handle the "dbus package got upgraded, let's switch to running the new code asap" use-case (which is the core thing people want to do), I think a nicer solution is to make dbus-daemon(1) exec(2) a new copy of itself passing all state (including fds with existing connections) to the new copy. I think init(1) does that. Of course, this is nasty business, you have to establish and maintain a stable restart-protocol... Of course this doesn't handle the case where dbus-daemon(1) segfaults but the other solution (handle restarts in apps) doesn't cover more interesting cases like dbus-daemon(1) hanging or otherwise malfunctioning. Either way, I personally think the whole "problem" is a gigantic waste of time to discuss so I usually avoid discussing it ... for me, it's totally a non-issue if you just accept that the Core OS is more than just code running in ring 0 and that we don't support this for the OS kernel either (yes, we all know about ksplice, no need to bring it up). So when people complain I tell them to write that dbus-daemon(1) patch if they want and that usually makes them go away. > (fwiw, g_bus_own_name() in gdbus could in theory make it considerably > easier to handle bus restart, assuming gdbus itself handles it.) Early versions of the gdbus code actually did that... but it made the code a lot more complex than it needed to be (resubmitting match rules, invalidating assumptions about the unique name being constant etc. etc.)... then I decided that the issue can (and I think, should) be fixed in the dbus-daemon(1) if you really want to... I, for one, don't care - but if someone writes a nice dbus-daemon(1) patch, we would probably accept it, right? David _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list