And with all the pike objects being referenced in the gtk2 object (and reverse), even if all the other objects are destroyed, if a pike object isn't, that is with gtk2, and that gtk2 object is a child in container, all it's parents will stay around too.

On Friday, December 22, 2017, 10:22:17 AM EST, Chris Angelico <rosuav@gmail.com> wrote:

On Sat, Dec 23, 2017 at 2:11 AM, Henrik Grubbström (Lysator) @ Pike

(-) developers forum <10353@lyskom.lysator.liu.se> wrote:

>>On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike

>>(-) developers forum <10353@lyskom.lysator.liu.se> wrote:

>>> Note that AFAIK destruct() in some GTK2 classes is a public function

>>> (and thus part of the API).

>>Do you mean destroy? It got renamed in the big _destruct rename, and

> Yes, the LFUN got renamed. The GTK2 API function however did not.

>>it was because I'd been using it that I started poking around and

>>finding this. But I'm quite okay with the API being "destruct(obj)"

>>rather than "obj->destroy()", as long as it works reliably.

> Using _destruct() for this kind of stuff is NOT a good idea as it gets

> called in a signal context.

Hmm. But there needs to be _something_ to cope with object

abandonment, otherwise a long-running process risks leaking resources.

So what SHOULD apps do? Not forgetting that an app may have to support

multiple Pike versions (currently I try to support 7.8->8.1), so

breaking changes have a cost.

ChrisA