hal_initialize() overrides other filter/object/fallback functions on separate connection

[Olivier Andrieu]

 David Zeuthen [Mon, 02 Aug 2004]:
 > (Followup from a message to the hal mailinglist since this involves
 > dbus; original message quoted in full)
 > 
 > On Mon, 2004-08-02 at 15:07 -0400, Dan Williams wrote:
 > > Hi,
 > > 
 > > Use the referenced testcase to verify and debug.  Symptom is that
 > > if hal_initialize is called, filter/object/fallback functions
 > > registered on another _separate_ DBusConnection never get called.
 > > 
 > 
 > Hi,
 > 
 > My tests confirm this is correct; the bug was that the libhal
 > message filter function always returned DBUS_HANDLER_RESULT_HANDLED
 > even though we didn't handle the message. Now we return
 > RESULT_NOT_YET_HANDLED for messages we don't handle (which is less
 > rude).

Indeed.

 > > Seems to be a dbus problem?
 > >
 > 
 > I think this is an issue with D-BUS, yes, why would the filter
 > function in the DBusConnection from libhal receive messages bound
 > for the DBusConnection made in your main application?

Well, when you call dbus_bus_get(DBUS_BUS_SYSTEM) several times, it
opens the connection the first time but then it just _ref() it. You
can't open it several times anyway, it's just one
/var/run/dbus/system_bus_socket.

-- 
   Olivier