hal_initialize() overrides other filter/object/fallback
functions on separate connection
Olivier Andrieu
oliv__a at users.sourceforge.net
Mon Aug 2 16:00:53 PDT 2004
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
More information about the dbus
mailing list