Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)

I tend to agree we should be avoiding reliance on main loops (or GC timing) to get the ref counts right if possible.

PyGObject also uses toggle refs similarly to gjs for keeping the wrappers alive. However, in PyGObject this only happens if a Python instance attribute is set. Whereas with gjs it seems to use a toggle ref all the time just in case an attribute is set?

It seems like the problem at hand can be solved by maintaining the floating ref and adding our own safety ref for the wrapper. With one caveat: upon completion of the python callback we may consider sinking the GObject if the ref is floating and the Python wrapper has a reference count greater than one. This basically means code in the callback made an assignment of the object to something outside of its scope and that should be considered a strong reference. But that might not even be necessary. I've attempted to describe this along with all the other problematic reference counting situations in a separate document:

The biggest concern at this point is how to properly deal with vfunc implementations which return objects and are annotated as "transfer none". Review, corrections, and feedback is very welcome.


On Fri, Jan 18, 2013 at 12:19 AM, Tristan Van Berkom <tvb gnome org> wrote:
On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna
<scampa giovanni gmail com> wrote:
> I know that Python doesn't have a GC in the traditional sense, but you
> could still send finalization for GObject wrappers to a idle callback
> so there is no risk of finalizing objects that C code assumes are
> still alive.

That doesn't sound like a very safe workaround to me.

There are situations where a lot of code can run without the mainloop
ever becoming idle, while running a ClutterTimeline is one of those
cases (or at least I've observed that idle callbacks dont generally
get called while a ClutterTimeline is playing, perhaps they do with
an ultra high priority).

Another thing to consider is that not all code written with the glib
stack is actually reactive & event based, code that does not run
a mainloop will risk blowing up in size quickly, possibly attaining
out of memory conditions unnecessarily if the code happens to
be highly recursive.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]