Re: DBus reconnect support (initial attempt)
- From: Havoc Pennington <hp redhat com>
- To: "Bill Rugolsky Jr." <brugolsky telemetry-investments com>
- Cc: dbus lists freedesktop org, networkmanager-list gnome org
- Subject: Re: DBus reconnect support (initial attempt)
- Date: Tue, 15 Mar 2005 10:21:36 -0500
On Tue, 2005-03-15 at 08:01 -0500, Bill Rugolsky Jr. wrote:
> If it is some huge bloated behemoth that may die due to bugs, or gets
> killed by the OOM-killer, etc., then apps must reliably reconnect. If
> it _can_ crash, it _will_ crash, quite often for certain workloads.
Well, there's no way to avoid "it can crash" - but it has a lot of unit
tests and does handle OOM. Of course, my understanding of the OOM killer
is that it can kill anything it feels like, so we could get nuked by it.
In a rational world we'd modify the kernel to avoid this, but the world
according to kernel is not always rational ;-)
> If it is compact, simple, and never crashes, then a less complex model
> fault model may be appropriate. But, at a minimum, I'd expect the
> system dbus to be able to checkpoint its state and rexec itself, with
> file-descriptors held open across exec() if necessary. It certainly
> wouldn't be the first daemon with such requirements.
My experience implementing this with gconfd is that it adds a ton of
complexity in and of itself...
] [Thread Prev