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
<ros...@gmail.com> wrote:
On Sat, Dec 23, 2017 at 2:11 AM, Henrik Grubbström (Lysator) @ Pike
(-) developers forum <10...@lyskom.lysator.liu.se> wrote:
>>On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike
>>(-) developers forum <10...@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
