Re: impending gdbus merge

[Mikkel Kamstrup Erlandsen <mikkel kamstrup canonical com>]

On Mon, 2010-05-10 at 12:50 -0400, David Zeuthen wrote:
> Hey,
> 
> On Mon, May 10, 2010 at 12:39 PM, Mikkel Kamstrup Erlandsen
> <mikkel kamstrup canonical com> wrote:
> > On Mon, 2010-05-10 at 12:28 -0400, David Zeuthen wrote:
> >> Hey,
> >>
> >> On Mon, May 10, 2010 at 11:09 AM, Mikkel Kamstrup Erlandsen
> >> <mikkel kamstrup canonical com> wrote:
> >> > I have two questions though. Firstly; why is there no API for installing
> >> > and removing generic match rules? They seem like such a fundamental
> >> > thing in DBus, and there alreay is API for installing filter funcs
> >> > anyway. Of course I can just call the AddMatch method asynchronously
> >> > myself, but having the convenience API like libdbus provides is mighty
> >> > handy.
> >>
> >> Hmm, g_dbus_connection_signal_subscribe() should do what you want.
> >
> > No :-) I need to listen for the RequestName method from any connection
> > and with a given arg0... But no need to cause a fuzz. I can still do
> > what I need via other means.
> 
> Sounds complicated!
> 
> (I'm curious: Why do you need to do this?)

I am writing a peer discovery framework. Peers all try and own the same
"swarm name" on the bus - that's how you register, by calling
RequestName(swarmname). The process owning the swarm name is the swarm
leader. There is more to it that this of course, but that's the core of
it. Fun stuff :-)

> >> If
> >> it doesn't.. well.. then you can always call AddMatch() yourself
> >> (easily, via a single g_dbus_connection_call() function call) and
> >> install a filter via g_dbus_connection_add_filter()... with all the
> >> threading-issues that involve.
> >
> > Which threading issues do you refer to here?
> 
> The docs for g_dbus_connection_add_filter() says
> 
>     Note that filters are run in a dedicated message handling thread
>     so they can't block and, generally, can't do anything but signal a
>     worker thread. Also note that filters are rarely needed - use API
>     such as g_dbus_connection_send_message_with_reply(),
>     g_dbus_connection_signal_subscribe() or g_dbus_connection_call()
>     instead.
> 
> > Would there be any trouble in installing the filter and then async
> > installing the rule - at least if I did it all from the main loop I'd
> > expect it to be safe?
> 
> Not sure exactly what that means... anyway, the only magic thing about
> filter functions is that they run in another thread.

Ok, cool.

Cheers,
Mikkel