Re: GtkApplication and argc/arv



Hey,

On Fri, Feb 25, 2011 at 2:28 PM, Havoc Pennington <hp 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]