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: https://live.gnome.org/PyGObject/Analysis/ObjectReferenceCountingForVFuncsAndClosures 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. Thanks, -Simon On Fri, Jan 18, 2013 at 12:19 AM, Tristan Van Berkom <t...@gnome.org> wrote: > On Fri, Jan 18, 2013 at 5:49 AM, Giovanni Campagna > <scampa.giova...@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. > > Cheers, > -Tristan >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
