Detectin mainloop integration

[Sebastian Dröge]

Am Donnerstag, den 27.09.2007, 11:17 +0200 schrieb Alexander Larsson:
> > Hm, dbus-gmain.c is AFL/GPL licensed it seems. I guess it would be
> > better for that library to be LGPL or MIT/X11, right? Does someone know
> > who is to be contacted for
> > 
> >  * Copyright (C) 2002, 2003 CodeFactory AB
> >  * Copyright (C) 2005 Red Hat, Inc.
> 
> I think LGPL is the best license for this. It already links to glib
> which is LGPL, so that is not a problematic license for the users of the
> library.
> 
> I think CodeFactory AB doesn't exist anymore, so that might be a bit
> problematic. It is ok for us to relicence the Red Hat owned parts to
> LGPL (or MIT if that is decided).

Ryan, you wrote in your dbus relicense mails somewhere that the
CodeFactory AB stuff was done under contract for Nokia. Did you get any
response from Nokia about it already?



> On Thu, 2007-09-27 at 09:33 +0200, Sebastian Dröge wrote:
> > Am Donnerstag, den 27.09.2007, 09:26 +0200 schrieb Sebastian Dröge:
> > > Am Donnerstag, den 27.09.2007, 09:06 +0200 schrieb Alexander Larsson:
> > > > On Thu, 2007-09-27 at 07:31 +0200, Sebastian Dröge wrote:
> > > > > Am Mittwoch, den 26.09.2007, 11:00 -0400 schrieb Havoc Pennington:
> > > > > > Hi,
> > > > > > 
> > > > > > On 9/26/07, Alexander Larsson <alexl at redhat.com> wrote:
> > > > > > > I totally agree. However, where is that place? A separate small
> > > > > > > libdbus-glib-main.so?
> > > > > > >
> > > > > > 
> > > > > > I don't see a lot of alternative - anyone have any other ideas?
> > > > > 
> > > > > ...and then having libdbus-glib-main.so be used in dbus-glib for the
> > > > > mainloop integration? Sounds ok IMHO
> > > > 
> > > > Yeah, its probably the only possibility. Its "yet another shared lib"
> > > > though. (And it has to be a shared lib so that multiple libs linking to
> > > > it will not conflict on the integration.)
> > > > 
> > > > Does anyone want to do this?
> > > 
> > > If nobody else wants to do it I could do it. Would anything apart from
> > > dbus_server_setup_with_g_main() and dbus_connection_setup_with_g_main()
> > > be needed or wanted in that new library?
> 
> I think that is enought. Possibly people might want a way to remove the
> mainloop integration for a connection (correctly refcounted so that it
> works if multiple libs do this).

I've already added such function locally. Also a function for checking
if the connection/server is integrated into a glib mainloop was added,
this is needed as the connection_slot variable is used in dbus-glib
in another place too (an assertion for checking if the connection is
integrated with a main loop).

Currently I have:

void dbus_g_main_connection_setup (connection, context)
void dbus_g_main_server_setup (connection, context)

gboolean dbus_g_main_connection_is_setup (connection)
gboolean dbus_g_main_server_is_setup (connection)

void dbus_g_main_connection_unsetup (connection)
void dbus_g_main_server_unsetup (server)


The naming is of course not nice yet, suggestions welcome :)
Maybe this should be renamed to:

_set_context
_has_context
_unset_context

or the other way around:

dbus_g_main_integrate_
dbus_g_main_unintegrate_
dbus_g_main_*_is_integrated

What do you think?

> I think the problem I had was that dbus_connection_setup_with_g_main
> owns the main context. Say you're using a custom mainloop + context pn a
> thread, and then you do an async gio call on this thread, with this
> mainloop. gvfs will then create a new peer-to-peer connection to the
> gvfs daemon, and integrate this connection with the supplied main
> context. However, when this thread later quits and unrefs of its main
> context the dbus connection ows a ref to it, so its leaked, and the
> connection isn't freed. What I wanted was that when the main context
> goes away the dbus connection is un-integrated and we can free it.

Owns? Well, it refs the main context and unrefs it when the connection
is destroyed (by connection_setup_free).

What's exactly the problem with your example? The thread will quit and
stop his main loop (which was integrated to the connection). When the
connection later is destroyed the main loop will also be unreffed.

Ok, now I see the problem, the main loops will only be freed when the
connection is destroyed and thus we could have many unused main loops in
memory.

A way around this would of course be the function to unintegrate the
main loop in the connection.

> Its easy to think of such cases where we want the dbus connection to
> live during the lifetime of a mainloop. Is there ever a case where we
> want the existance of a dbus connection to affect the lifetime of a
> mainloop?
> 
> I don't think it ever really makes sense to integrate the shared session
> bus with anything but the default main context, and then both objects
> live forever, so that case is not very interesting. 

It's only possible to set one main loop for each connection. Having the
shared session bus integrated in something else than the default main
loop calls for trouble. Would it make sense to allow setting several
main loops for each connection? I can't think of a useful use case ATM.

> So, we have left
> three cases:
> 1) Private connection integrated with default mainloop
> 2) Private connection integrated with a custom mainloop 
>  a) We control the custom mainloop
>  b) The custom mainloop was supplied from outside
> 
> (case 2b is the gvfs case)
> 
> I see three possible ownership solutions:
> A) The integrated connection owns the mainloop
> B) The mainloop owns the integrated connection
> C) No ownership, both refs are weak

How do you want to implement B)? There's nothing like a destroy notify
for GMainContext unfortunately and I see no other way of unreffing the
connection while the GMainContext disappears. So we only have A) und C)
left IMHO.

Also when choosing B) it would be weird that a connection can only have
one main context but a main loop can have many connections.

> How do these solutions affect memory management in the three cases
> above:
>
> [...]
>  
> Clearly, solution B is the only one that gives reasonable behaviour for
> case 2b. However, choosing that does affect how the other cases are
> handled. In particular, it requires the introduction of an untegrate
> call so that case 1 can be handled.
> 
> This means the code has to be restructured a bit though. The gvfs code
> actually uses solution C atm, which is not ideal. However, it is
> probably a better base for an implementation of solution B.

So what are exactly the properties you want to have?
You definitely want that the connection is alive exactly until the main
loop is stopped, so the main loop somehow has to own a reference on
the connection and we need some way to unref the connection when
the main loop quits.

Do you also want to have a connection serving more than one main loop?