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

[nf2]

Thiago Macieira wrote:
> 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).
>   
The API doc says that private connections are always "new".

>   
>> 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.
>   
Never mind, that has just been a theoretical question ;-)
>   
>> 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.
>
>   

I think you can. But maybe i didn't understand the code. I thought 
that's how different libraries in the Glib world work together (i think 
Havoc mentioned something like that).  Some use the GLib-DBus mainloop 
glue, and others bring their own. The last one who registers, will 
remove the previous. For instance GVFS also uses D-BUS heavily, also the 
shared session bus connection, but doesn't use the GLib-DBUS bindings.

have a look at:

_dbus_watch_list_set_functions() (which gets called from: 
dbus_connection_set_watch_functions())

it says:

/* Remove all current watches from previous watch handlers */


http://dbus.freedesktop.org/doc/api/html/dbus-connection_8c-source.html
http://dbus.freedesktop.org/doc/api/html/dbus-watch_8c-source.html


>> (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.
>   

Of course - if they don't use the same main-loop, they can't use async 
libraries. Because you can never be sure if such libraries also watch 
other (non D-BUS) fd's in their main-loop. I guess inotify is a popular 
candidate...

Cheers,
Norbert