so the kernel can send d-bus messages

[Havoc Pennington]

On Sat, 2004-07-24 at 18:25, Bastien Nocera wrote:
> On Sat, 2004-07-24 at 17:42 -0400, Havoc Pennington wrote:
> > On Sat, 2004-07-24 at 16:07, Sean Middleditch wrote:
> > > Hmm.  Doesn't D-BUS need to be restarted whenever the settings change,
> > > like adding a new bus configuration?  If we have D-BUS able to reload
> > > these without shutting down, that'll be a lot better.
> > 
> > trow already fixed this, so that HUP will reload config.
> 
> That doesn't quite fix it...
> For example:
> - launch an application that uses HAL
> - restart HAL
> - the application is hung
> 
> The problem is all the clients that you would have to restart if dbus,
> or hal, or one of the possible dbus related daemons has to be restarted.
> It's stateful, it's hard, and it's not fixed yet...

The idea is that dbus-daemon doesn't have to be stopped or restarted...
this is what trow's patch allows.

HAL is a separate problem, but it should be possible to write apps that
track HAL lifecycle and respond appropriately. Writing the app in an
event-driven way should get this right, i.e. the initial communication
with HAL should be tied to the "HAL daemon appeared" event and thus be
repeated when it reappears.

To support dbus-daemon restarts, we could take a similar approach in the
libdbus API by forcing apps to be written async, i.e. make
dbus_connection_open() async, along with dbus_bus_get(); then app
authors have to write a connection_established_callback() which could
reasonably be called multiple times.

We could give that a try, but it might be sort of annoying for simple
command line apps.

Something like:

void
connection_established_callback (DBusConnection *connection)
{


}

int main()
{
  dbus_set_bus_connection_callback (DBUS_BUS_SYSTEM, 
                                    connection_established_callback);

  dbus_bus_retry_connection (DBUS_BUS_SYSTEM);
}

Where retry_connection() queues a system bus connection to be attempted
when the main loop runs, and eventually establishes the connection and
invokes the callback. If the connection drops retry_connection() is
automatically called again.

If someone wants to prototype and see if this works and/or sucks, that
would be cool.

Havoc