Michael spaketh: > This reminds me a bit of http://bugreports.qt.nokia.com/browse/QTBUG-11712-- > do you think this may be related to what you are seeing? Do you have any > small examples of strange out-of-order behaviors you could share (I'd like > to understand the problem better)? > > I spent some time looking at that bug -- very interesting. Thanks!
Yes, this might be the same thing that I'm seeing. I agree with the original comment, that without some "preference" that (1) bound properties are updated first, and (2) ONLY THEN onXXXChanged slots should run (undetermined order is fine). I think that will fix my problem. This might be my *entire* issue, so I voted for it and am now watching that ticket. Still, I'm thinking about the "corner cases" to different designs where fundamentally, it might be unclear "what you can trust" (e.g., bound properties? Unbound properties? Slots? Imperative calls triggered from different slots with undetermined order?) It's kind of an interesting problem marrying "declarative" and "imperative". I suppose globalizing the topic would reduce it to the *same* set of issues for any multi-threaded model (e.g., handling resources across synchronous and asynchronous threads). However, for explicitly threaded models like that, one tends to design a model where those resource locks/updates are understood (to avoid collisions) or "repairable" (to "heal" from past collisions). It's not yet obvious to me how to handle that with the QDeclarative "way" for non-trivial systems (e.g., I tend to work on heavy desktop apps). For example, if I "trusted" a not-yet-updated property (e.g., did work based on the stale value), and the value (in parallel) was updated, I might not be able to detect that I need to re-do that work. So, summary question: Is there guidance on the internal thread model within the Declarative engine (e.g., how is work distributed on threads, their priorities, and when other threads are created?) (Is this too big a question, or not sufficiently defined within the Declarative engine at this point, as we are seeing discussions like this and QTBUG-11712?) -charley
_______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
