hal_initialize() overrides other filter/object/fallback
functions on separate connection
david at fubar.dk
Mon Aug 2 17:00:59 PDT 2004
On Tue, 2004-08-03 at 01:00 +0200, Olivier Andrieu wrote:
> > > 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.
Hey, guess I just should have read the documentation :-).
However, I'm not convinced, though, that this behavior is always desired
considering that the DBusConnection's got state; e.g. you subscribe to
signals on a per-connection basis.
So, in particular, this is bad if you have several (distant) parts of
the same process communicating with the same D-BUS service in the other
end. With distant I mean that the different parts of the process are not
necessarily aware of each other (think processes that dlopen() stuff)
and that the process per se isn't written to use D-BUS.
So it would be nice to have a dbus_bus_get_no_recycle() function,
however, I'm sure the name of the function can be improved.
> can't open it several times anyway, it's just one
Hmm, why is that? AFAICT this is plain UNIX domain sockets. And I'm sure
that platforms lacking UNIX domain sockets got similar mechanisms.
More information about the dbus