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

[David Zeuthen]

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.

> You
> can't open it several times anyway, it's just one
> /var/run/dbus/system_bus_socket.

Hmm, why is that? AFAICT this is plain UNIX domain sockets. And I'm sure
that platforms lacking UNIX domain sockets got similar mechanisms.

Cheers,
David

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal