Hiding internal DBUS use inside a library

[Colin Walters]

On Tue, 2005-08-23 at 21:48 +0200, Lennart Poettering wrote:
> Hi!
> 
> I am working on a library that makes internal use of DBUS. It connects
> to the system bus and does some work there. I want to hide the fact
> that the library uses DBUS completely. Unfortunately this is not
> possible wth the current API, as it seems. Due to connection recyling
> we might get access to a connection some other part of the application
> (maybe some other library?) registered and might have installed
> watch/timeout handlers for. If we now overwrite those handlers with
> our own DBUS goes nuts.

Ultimately, you can only have one main loop (well, per thread) in your
application.  Now, I did run into the connection sharing problem between
two threads with separate mainloops.  I have a partial patch to add an
API to get unshared connections, so that e.g. the GLib bindings can have
one connection per mainloop.

> In short: a library that uses the current API function dbus_bus_get()
> is simply broken.

Not necessarily - if the library doesn't install its own handlers on the
connection, but e.g. instead just does dbus_connection_send and returns,
or does dbus_connection_send_with_reply_and_block.  The former
definitely works, the latter *should* work conceptually; whether it
currently does or not is another question :)

> Honestly I think that the whole connection recycling thing is a really
> bad idea. The fact that one part of a process might call functions
> like dbus_connection_set_timeout_functions() 

But you're going to have a serious problem anyways if you have two main
loops in your application.  In what situation have you found this to be
a problem?

> or
> dbus_connection_set_max_received_size() 

Yeah...somewhat problematic, although this is kind of a specialized
function.  It probably isn't something any library should be invoking.

> And when does this connection recycling ever become handy? 

I think one of the goals was to reduce the number of open file
descriptors desktop applications have.

> Would a patch that removes the connection recyling entirely be
> accepted?

I don't think so, not without more discussion.

> In case not: would a patch adding a new function
> dbus_bus_get_private() which is identical to dbus_bus_get() but uses
> dbus_connection_new_private() internally, be accepted?

I have a patch in progress for that which will be needed for the
per-mainloop connection.


-------------- 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/20050825/e9a62aa8/attachment-0001.pgp