other filter/object/fallback functions on separate connection
richard at imendio.com
Tue Sep 28 11:14:06 UTC 2004
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
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.
Imendio HB, http://www.imendio.com/
More information about the dbus