hal_initialize() overrides other filter/object/fallback
functions on separate connection
David Zeuthen
david at fubar.dk
Sun Aug 8 03:23:47 PDT 2004
On Sat, 2004-08-07 at 23:19 -0400, Havoc Pennington wrote:
> On Sat, 2004-08-07 at 21:09, David Zeuthen wrote:
> > Specifically, the BarService emits signals on certain objects. libbar
> > may choose, at the discretion of the user of a libbar instance, to
> > listen for all signals on all objects, but if there is only one
> > DBusConnection only one of the libbar instances gets the signal. Which
> > is a problem. Having libbar use dbus_bus_get_dedicated() solves this
> > problem.
> >
>
> If all the signal handlers return NOT_YET_HANDLED, does it solve the
> problem?
>
That would solve that particular problem, yes, but it also introduces
another problem: libbar no longer has control over what signals it asked
for. In a way, that implies double bookkeeping.
An example: libhal provides an interface that says ''tell me when
properties for this device object change'' and an application programmer
might want to do this when he sees a device object he likes. This could
be the ethernet adapter that is being used as the default connection
(e.g default route) and he is interested in the signal that says ''link
status has changed''. Now, another instance of libhal in the process
have requested to get all properties changes on all device objects and
there is the problem.
Without dbus_bus_get_dedicated() libhal, or the application author,
would have to keep track of the signals requested in order to continue
to provide this API.
> Maybe the root issue is that for a method call, you want only one
> handler, but for a signal, you probably want all the handlers to run.
> That might be the better place to fix the problem... hmm.
I'm not sure, it's difficult for me to articulate, but wanting to push
all signals to all handlers is somewhat similar to problem we have with
UNIX signals and libraries, e.g. you can't, as a library, really rely on
handling UNIX signals in transparent way to the process using you. Of
course the problem isn't that bad, since adding a filter doesn't remove
the other filters like with signal(2).
It just seems wrong to me that a library, like libhal, always have to
assume the DBusConnection is shared. Are there any problems,
architectural or otherwise, with the concept of get_dedicated(), other
than resource consumption and bloat of course, that I'm not seeing?
Cheers,
David
More information about the dbus
mailing list