Detectin mainloop integration

[Sebastian Dröge]

Am Donnerstag, den 27.09.2007, 16:31 +0200 schrieb Alexander Larsson:
> On Thu, 2007-09-27 at 15:32 +0200, Sebastian Dröge wrote:
> 
> > 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'd like the integrate versions. Since thats what it does. It integrates
> two different systems.

Ok, good :) Is unintegrate an existing english word?

> > > 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.
> 
> When the GMainContext is unref:ed it destroys all the sources attached
> to it. This will unref any callbacks in the source, and the destroy
> notify for it (passed to g_source_set_callback) will be called.

Ah, good point. Yeah, should work fine that way :)

> > 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 is this weird? You can only add a connection to one context, because
> otherwise multiple threads would dispatch from the same connection which
> is totally crazy. However, there is nothing weird with having multiple
> conntections (maybe even to different endpoints) being dispatched to the
> same thread. (In fact, thats the normal case.)

Nevermind, I was just confused.

> > > 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.
> 
> Yes. See above.

Ok, so I'll change everything to the naming we've chosen above and B),
i.e. having the connection unreffed when the main context gets
destroyed.

The latter will probably be hard to integrate into dbus-glib to get the
same behaviour as we have now. Can you think of any problems other than
memleaks that could arise when just having the dbus-glib functions call
or B)-style functions from dbus-glib-main?