Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
- From: Tristan Van Berkom <tvb gnome org>
- To: Simon Feltman <s feltman gmail com>
- Cc: Torsten Schoenfeld <kaffeetisch gmx de>, gtk-devel-list gnome org
- Subject: Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
- Date: Tue, 5 Feb 2013 16:05:50 +0900
On Tue, Feb 5, 2013 at 12:08 PM, Simon Feltman <s feltman gmail com> wrote:
> I could easily be misunderstanding the internals, but at some point isn't a
> call to something like gtk_widget_set_parent on the children needed for
> widgets to ever be displayed or useful? (which sinks the children)
One of the more gross internal details of GTK+ is that GtkWindows
(any toplevel widgets) get added to an internal 'list of toplevels'.
So a GtkWindow is an odd subclass that (like someone else
pointed out), sinks it's own floating reference at initialization time.
The ownership of the window is virtually given to "GTK+" and then
disposed of automatically at gtk_widget_destory() time.
I suppose that strictly speaking, an object constructor can indeed
have side effects (but I can't think of any case where it would be
anywhere close to 'sane' to intentionally use object constructors
for their side effects and ignore the results).
Best,
-Tristan
>
> If it really might be a problem we could work around the leak by tracking if
> the instance was created within python and if the instance has ever been
> marshaled to C. At which point we could rely on the GC cleanup of the
> wrapper to sink and unref the extra ref in cases the GObject was never
> passed on to C at any point. This sucks but it seems a little better than
> checking GObject ref counts during marshaling and floating sunk objects
> based on if it was initially floating and the GObject ref count is only 1,
> which might be unsafe.
>
> -Simon
>
>
>
> On Mon, Feb 4, 2013 at 4:56 AM, Torsten Schoenfeld <kaffeetisch gmx de>
> wrote:
>>
>> On 04.02.2013 03:39, Simon Feltman wrote:
>>>
>>> I am starting to warm up to an idea where we simply never sink objects
>>> and always follow the rules entailed by
>>> ownership transference annotations already in place, with one caveat:
>>> g_object_new is annotated as transfer full but can also return floating
>>> references. In this case, we must check the returned type and not
>>> believe the annotation when it returns InitiallyUnowned instances, but
>>> instead treat it like transfer none and add a new ref.
>>
>>
>> What about custom implementations of classes that are supposed to take
>> over floating refs? For example, how would you write a custom GtkContainer
>> subclass in Python with your scheme? Wouldn't you then need a way to
>> explicitly sink the floating ref?
>>
>> _______________________________________________
>> gtk-devel-list mailing list
>> gtk-devel-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]