[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_edi
From: Simon Feltman <s.feltman () gmail ! com>
Date: 2013-02-05 3:08:32
Message-ID: CACc9j8Y=58SSZSO9_anmC9-WS3BkoNsAOt9DPWZPeNJRHRJ04w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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)
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<https://mail.gnome.org/mailman/listinfo/gtk-devel-list>
>
[Attachment #5 (text/html)]
<div dir="ltr">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)<div>
<br></div><div>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.</div>
<div><br></div><div>-Simon</div><div><br></div><div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 \
at 4:56 AM, Torsten Schoenfeld <span dir="ltr"><<a \
href="mailto:kaffeetisch@gmx.de" target="_blank">kaffeetisch@gmx.de</a>></span> \
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div>On 04.02.2013 03:39, Simon Feltman wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I am starting to warm up to an idea where we simply never \
sink objects<br> and always follow the rules entailed by<br>
ownership transference annotations already in place, with one caveat:<br>
g_object_new is annotated as transfer full but can also return floating<br>
references. In this case, we must check the returned type and not<br>
believe the annotation when it returns InitiallyUnowned instances, but<br>
instead treat it like transfer none and add a new ref.<br>
</blockquote>
<br></div>
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?<div>
<div><br>
______________________________<u></u>_________________<br>
gtk-devel-list mailing list<br>
<a href="mailto:gtk-devel-list@gnome.org" \
target="_blank">gtk-devel-list@gnome.org</a><br> <a \
href="https://mail.gnome.org/mailman/listinfo/gtk-devel-list" \
target="_blank">https://mail.gnome.org/<u></u>mailman/listinfo/gtk-devel-<u></u>list</a><br>
</div></div></blockquote></div><br></div></div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic