[Development] [QML] Singletons are deleted before the other objects

[Simon Hausmann]

On Wednesday 24. September 2014 23.10.01 BogDan wrote:
[...]
> Hi,
> 
>   Do we all agree that the singletons, by definition, must be available to
> any object at any time until the end of the application?

Yes, with emphasis on "until". Note that we are now talking about the "end of 
the application" situation, so our agreement ends right there ;-). We are 
talking about the time the QQmlEngine destructor is executed, which from a QML 
engine perspective is the "end of the application" point of time. What happens 
during that period of time is just as "fishy" as when tearing down a C++ 
application: The order of destruction for global objects between several 
compilation units is undefined. In C++ you cannot rely on it (I think you can 
rely on the order within a unit), so you prepare yourself with levels of 
indirection and/or weak references.

Right now the order of destruction in the QML engine is defined like this (by 
the existence of one implementation only):

1) Singletons are deleted first
2) The remaining JavaScript objects are deleted at random

We can't change (2) really and we can't swap step 1 and 2 because it breaks 
for singletons that _are_ JavaScript objects.

(to be continued further down)
 
>   IMHO deleting first the QML singletons then the rest of the Active objects
> is also wrong, because some of the active objects might need these
> singletons.
> 
>   I think the right way is to delete all the active objects first, then QML
> singletons, try delete again all the active objects (supposing that the QML
> singletons will create new objects in Component.onDestruction), then at the
> very end, all the C++ singletons. IMHO this is the right way to do it, and
> is not a hack at all. Doing something right, even if it's harder, is not a
> hack ...

And I feel that this is trying to solve a problem at the wrong level, hence me 
calling it a hack. No doubt we have many hacks in place, but they come at a 
cost of maintenance and complexity an already complex shutdown procedure. (/me 
points to qdeclarativeelement_destructor :) . So if we wanted to add this 
complexity, then I think it needs a better justification. I'm afraid I don't 
see that yet.

At run-time you can rely on the life time of singletons. When the application 
is being shut down and you rely on a specific order of destruction, then I 
think you have to take care of it in your application. (And we may be missing 
tools to achieve that)

Note that this is separate from the order of destruction "between" singletons 
- here it might makes sense to implement destruction in reversal to 
construction, although construction is non-deterministic from the framework's 
point of view.
 
>   I don't see how using a weak pointer will fix the problem, who will delete
> the singleton object in the end? 

As we have established earlier, the singleton _does_ get deleted by the 
engine. The subject of this email thread gives it away :).

Hmm, I apologize, I may have misunderstood or rather misinterpreted an earlier 
statement of yours about what's happening. I understood "active objects may 
still need to access the singletons in their destructor" as pointer based 
access and I (perhaps mistakenly?) concluded that you're experiencing crashes 
from users of the singleton _to_ the singleton due to dangling pointers. If 
that's not the case, could you elaborate a bit on what kind of access this is?

>>> I can't reference it
> for every object that depends on it, because,  BTW, there are cases when
> the VM doesn't delete all the objects! Yes it has lots of memleaks at the
> end!

What are you trying to say here? Is throwing mud supposed to motivate and 
convince me? :(

If there are memory leaks, then I think we agree that those should be fixed. In 
this email thread we are talking about semantics during engine shutdown.

At this point it's your word against mine :). You can try to convince me to 
invest time to implement the behavior you'd like. You can try to implement it 
yourself and convince me or some other approver to approve the change. Or you 
can try to convince somebody else to implement the change.


Simon