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

[Havoc Pennington]

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.

Remember another solution possibility raised, the "socket multiplexing"
thread. That solution sounds complex at first but I'm not sure it really
is; it might amount to only a few days of work. Not sure if it helps
with threads or not though. Effectively the idea is to have multiple
DBusConnection all going to the same file descriptor. So at first glance
it's just an optimization; but if we can rely on this optimization, we
could change the API to assume more private DBusConnection will be
created. Or alternatively, have a DBusConnection include multiple
message queues (one for each registered object perhaps?) and then stick
to a single global DBusConnection. That seems to sort of definitively
eliminate the shared message queue problem. All of this has some
complexity cost; basically it needs to be prototyped and thought about.

If the lib in question is a platform lib, in my view adding an
additional DBusConnection that most apps will open is a fairly negative
thing resource-wise in the current dbus implementation.
 
> 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.

I think this is a reasonable code organization thing regardless of the
above discussion, but you do have to check for
DBUS_SESSION_BUS_ADDRESS=bus:type=session sort of issues. And you have
to ban bus: addresses as addresses to listen on, they can only be used
on the "client" (connecting) side.

Havoc