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

[Richard Hult]

David Zeuthen wrote:
> Hi,
> 
>> A possible other way to do this is to have an address passed to 
>> dbus_connection_open() that refers to a bus, e.g. instead of 
>> unix:path=/tmp/foo maybe bus:type=system - this would not do any 
>> communication/registration with the bus though, or maintain a 
>> global bus connection, it would just open a connection and 
>> encapsulate the way to find the bus address. (Env variable, etc.)
> 
> That could work as well, it just seems a bit backwards to me.

Was there a consensus on this? There's another reason to have a way to
get a "dedicated" bus connection: when dbus is used in a threaded
library. An example:

libfoo uses dbus as an internal implementation detail, and needs to do
work over dbus in a specific thread. No dbus API is exposed and users of
this library aren't necessarily aware that it uses dbus.

The application bar uses libfoo, and also uses dbus (in the main/only
thread).

In order for this to work, there must be two separate dbus connections,
since the application has no idea that the lib uses dbus from another
thread.

The simple suggestion from Havoc to have an address type like
"bus:type=system" would be totally sufficient for this kind of case. The
common and preferred way would still be to share the connection, but for
cases where it's not possible, there would be a way to get a separate
connection.

Any comments on this?

/Richard

-- 
Imendio HB, http://www.imendio.com/
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal