Page MenuHomePhabricator

evas: Avoid call of efl_del without parent
Changes PlannedPublic

Authored by lauromoura on Sep 9 2019, 1:13 PM.

Details

Summary

efl_del should be used only when an object has a parent.

The previous code leads to efl_del error messages in C# due to being
called on objects already without a parent. We can't guarantee the order
the objects in C# are collected, even if they have a parent-child like
relationship.

Fixes T8216

Diff Detail

Repository
rEFL core/efl
Branch
move_owned_binding
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 13196
Build 9364: arc lint + arc unit
lauromoura created this revision.Sep 9 2019, 1:13 PM
lauromoura requested review of this revision.Sep 9 2019, 1:13 PM
zmike added a comment.Sep 9 2019, 1:15 PM

I recall adding something like this previously and then @cedric said to do something else instead

I recall the same, but we still have this issue, and i think we really should do something like this, the logs of our test suite is full of this.

It is my understanding that Evas is always in the parent chain and has ownership. So it should always be able to do an efl_del. If it can not, it should be reported as an error and we should investigate why it is happening.

One of the case I have noticed that we do not handle well at all is when there is a reference outside of Evas on a child. We should properly disconnect the Evas object and not reference the canvas anymore on efl_del even when there is still reference hold on the object, but this is a different behavior than legacy as legacy would just blast any reference still owned. What a mess. Oh and there is also the del, but not completely del yet state. Anyway.

In bindings it can happen that a object has a ref while it gets efl_del'ed. Which will leave it unparented. Additionally, you can create Efl.Ui.Win with efl_new so i think this is required.

Isn't the issue that we shouldn't force destroy object in Evas on canvas shutdown actually?

lauromoura planned changes to this revision.Mon, Sep 23, 1:15 PM

So, holding this back for further discussion.