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

[Richard Hult]

Havoc Pennington wrote:
> On Sat, 2004-09-11 at 00:44 +0200, Richard Hult wrote:
> 
>> 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.
> 
> 
> I'd like to understand how dbus is different from Xlib in this case. 
> There are threaded X apps where threads (and various libraries) share
> an X connection, right? What is the aspect of dbus that makes it
> different from X?
> 
> I'm not saying there isn't such an aspect, but I'd like to understand
>  it.

The main difference seems to me to be that in the case of X it's more 
explicit that X is used, while dbus can be used as more of an 
implementation detail in a library, although I might be wrong there.

The problem I see with the situation I described in the previous mail is 
that the threaded "libfoo" needs to initialize the dbus thread support, 
but there is no guarantee that the application that uses libfoo and also 
uses dbus, doesn't call some dbus_* functions before the library gets a 
change to initialize the thread support.

/Richard

-- 
Imendio HB, http://www.imendio.com/