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

[BogDan]

[..]
> >  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.
> 

I don't see a better justification than the fact that this is the right way to do it ....

> 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)


I can't do it in my application, I'm trying to create a standalone QML *plugin* and I have no control when it's created/destroyed.


[..]
> 
> >  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?

Yes, that is the case and I still fail see how a weak pointer will help me to fix the problem...
I'm using the the singleton as a central manager for file handles, memory allocators and many other resources. When a new object is created it uses this singleton to create and access its resources and when is destroyed it needs to use the same singleton to save some data, but the singleton it's not there anymore so it can't save its state and release its resources.

Of course this is my use case, but you'll find many other use cases when a singletons must be the very last object that needs to be deleted. E.g. a Settings singleton which the active object needs it to save their states...

> >>> 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? :(
> 

No, not at all! I'm sorry if you see it that way ... I just tried to explain why your proposed workaround doesn't work... 

[..]
> 
> 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.


If you check the thread from the beginning you'll see that I'm not the only one who thinks that the current behavior is wrong.
IMHO your approach is wrong, we all agreed that the current singletons behavior is not ok, but you still want use cases in order convince you that it needs to be fixed :). It is impossible for me (and for everybody else) to give you all the possible use cases out there when the singletons must be deleted last...
IMHO you should ask yourself if there is any use case when the singleton should be deleted first ;-)...

I think it will much faster to implement it myself :), if nobody wants to approve it, then I'll just keep for myself ;-)...


Cheers,
BogDan.