Detectin mainloop integration

[Sebastian Dröge]

Am Freitag, den 28.09.2007, 11:55 -0400 schrieb Havoc Pennington:
> Hi,
> 
> Some thoughts:
> 
> 1) are setup/unsetup really doing a refcount? (so they have to be
> called a paired number of times?) I would say they should

Refcount on what? They currently ref/unref the main context that gets
set and in my local branch ref/unref the connection (from the GSources,
unref happens when either it's unsetup or the GMainContext gets freed).


For themselves it makes sense to call setup more than once, even when
there's only one corresponding unsetup somewhere, as with the current
behaviour it simply unintegrates from the old GMainContext and
integrates into the new. Do you think it makes sense to stop this
behaviour?

> 2) is is_setup() useful?

Probably not... it would be more useful to have a function to return the
maincontext in which this connection/server is integrated but even that
is most probably useless.
I only added it now because of a assertion in dbus-glib
(dbus_connection_get_g_connection).

> 3) should we add API to libdbus that is more like:
>    typedef struct {
>           DBusSetupConnectionFunc setup_connection_func;
>           DBusSetupServerFunc setup_server_func;
>           void (* padding1) (void);
>           ...
>    } DBusIntegrationFunctions;
>    dbus_set_integration(const char *name, const
> DBusIntegrationFunctions *funcs);
> 
>    An example of the difference here is that on calling
> dbus_connection_open() or dbus_bus_get(), the returned connection
> would already be integrated. For dbus_connection_open_private()
> probably it would not be. Without this approach, we probably need a
> bus_get() equivalent at least in the glib integration lib.
> 
>   This may be a "future elaboration" though, we could do just a
> setup_with_g_main() split-out from dbus-glib for now.

Such DBusSetup*Func would need to take some custom parameters though,
for the glib case for example it must be possible to select into which
main context we want to integrate. So dbus_get() or
dbus_connection_open() would need to take that additional parameter too
which would break API. I guess that's not feasible.

> 4) I'd be inclined to stick this glib integration lib into the main
> dbus tarball. It does not seem big enough to me to mess with as a
> separate thing. I'm also inclined to eventually merge some parts of
> hippo-dbus-helper or some kind of C convenience lib into the main dbus
> tarball. Are there big downsides to doing so?

Sounds good, having such <1000 line library separate is insane :) Also
having some kind of C convenience lib is definitely needed IMHO.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070929/8a630db5/attachment.pgp