C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?)

[Thiago Macieira]

nf2 wrote:
>For instance i didn't know that QtDBus only uses private connections. Is
>that right?

Yes.

>Thus if Qt or KDE uses GLib based libraries which use the 
>shared connections, there won't be any problem (if Qt is compiled with
>GLib-Main-Loop. Having multiple connections to the session daemon might
>be a bit inefficient - but at least it works - and there won't be more
>than two connections, because all the KDE/Qt stuff will use the private
>QtDBus session bus connection and the rest will use the shared
> connection).

That's correct (supposing, of course, that no one opened an extra private 
connection for their own purposes).

>If there is something special about how QtDBus uses it's private
>connections. Could it be fixed without breaking the QtDBus API, and Qt
>could also use the shared connections? (just to avoid having two
>connections?)

See one of the emails I posted as a reply to Havoc. I explained the 
reasons that led me to use the private connection.

Besides, I have no intention of dedicating any time to that. It's already 
working the way it is and I'm not going to yank out a major part of the 
code, introduce a lot of bugs just for a small gain.

>Another thing i didn't know is how the dbus watches work. For instance
>that you can call dbus_connection_set_watch_functions() on a connection
>multiple times, so that every library can bring its own main-loop glue

You can't set that multiple times on the same connection. But each 
connection has its own mainloop glue.

>(Which will usually do the same thing, assuming that GLib-Main-Loop is
>the standard main loop - which - i believe - it should be in Linux/Unix
>anyway ). 

Not so if you take into account other toolkits. libdbus-1 will also not 
link to glib.

Even if we yanked it out and placed it in a separate library and then made 
both glib and Qt use it, there are still other mainloop implementations, 
not to mention legacy versions.

>When dbus_connection_set_watch_functions() is called again, 
>all the old watches will be removed from the connections filedescriptor.
>is that correct?

No. It adds them to the new one, but doesn't remove from the old one.

(And it shouldn't: you shouldn't call that function twice)

>One thing i don't understand is: does every main-loop glue always have
>to live until the end of the application process? Why is there no stack
>of watch function sets for every connection. Lets consider two libraries
>using the shared session bus connection (and bringing their own main
>loop glue)
[impossible situation snipped]


-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070804/13d803c3/attachment.pgp