Re: impending gdbus merge
- From: Christian Persch <chpe gnome org>
- To: gtk-devel-list gnome org
- Subject: Re: impending gdbus merge
- Date: Thu, 13 May 2010 13:52:57 +0200
Hi;
Am Wed, 12 May 2010 13:22:34 -0400
schrieb David Zeuthen <zeuthen gmail com>:
> On Wed, May 12, 2010 at 9:51 AM, Christian Persch <chpe gnome org>
> > - g_bus_own_name has a _on_connection variant that directly takes a
> > GDBusConnection*; maybe g_bus_watch_name and g_bus_watch_proxy
> > shoule also have such a variant.
>
> Sure, if it turns out we need such variants we can always add them
I actually used g_bus_watch_name() in a situation where I already
had a GDBusConnection* available, so being able to pass it directly
instead of by type would be good.
> > - should g_bus_unwatch_name/proxy call the name/proxy_disappeared
> > callbacks, if the name/proxy_appeared callbacks have been called
> > before? It appears they don't. (I checked the watch_name one; I
> > assume watch_proxy is the same?) It would be nice not to have to
> > manually clean up after calling unwatch, when I also do the same in
> > the disappeared-callback.
>
> It actually used to be like that. This is why we changed it
>
> Don't guarantee that on_name_lost() will be called after
> g_bus_unown()
>
> This guarantee made it impossible to use g_bus_own_name() from
> within a GObject e.g. by called g_bus_own_name() in constructed() and
> g_bus_unown_name() in finalize() because on_name_lost() was
> delivered in an idle.
>
> With the way things work now, you are guaranteed to *never* get
> callbacks if you call g_bus_unown_name() from the same thread from
> where g_bus_own_name() was called....
Ok, that makes sense :)
The docs for g_bus_unown_name/unwatch_name/unwatch_proxy should
definitely mention this.
Regards,
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]