[email protected]
[Top] [All Lists]

RE: How to make execution of slots deterministic

Subject: RE: How to make execution of slots deterministic
From: <>
Date: Fri, 24 Oct 2008 17:37:32 +0200
Scott Aron Bloom wrote on Friday, October 24, 2008 4:42 PM:

> ...
> For QT-Embedded, Nokia may want to consider documenting the current
> algorithm, stating for QT 4.X.X the order of connected functionality
> is this.  And make that part of the binary compatibility requirements
> for release.

First, how would you make sure that changing the order of slot calls would 
break "binary compatibility"? Because it would not! Changing the 
/implementation/ only does /not/ change "binary compatibility" (your code would 
still run with such a changed Qt library, because it would still be "binary 
compatible" - it would simply behave wrongly and possibly crash, but not due to 
"binary incompatibility").

But even if the docs would state that "the order of slot execution" is in the 
"order of connection" I would feel uncomfortable if my design had to rely on 
that *implicit* implementation detail.

I mean if you are sure that you are connecting only 4 signals - and only those 
4 signals! - and the corresponding slots have to be called in that and that 
order, and you connect them "statically" in one place (in some c'tor which is 
only called once during application lifetime or so), you could probably live 
with that.

But my experience shows that as soon as an application becomes a bit more 
complex signal/slot handling can very quickly become very complicated to 
understand! ("One signal triggering a slot, triggering another slot which 
triggers another signal...", or the same slot called multiple times, because 
with each little change the model emits a signal, ...)

Adding to that the fact that signal/slots can be *dynamically* 
connected/disconnected at runtime, how would you make sure that no other code 
has "connected that slot which was meant to be connected *after* your slot 
which you are about to connect"? Etc.

Trying to debug something like that is likely to become a nightmare. Why? 
Because you are using *implicitly* the fact that slots are called in the order 
of connection. But if you connect from different places in code... uh oh...

So IMHO it is better to use an *explicit* design, with slot Priority or a 
"Manager" class, which would not depend in which order you would connect (but 
would only rely on the explicitly set "Priority", or the other mentioned 
solution, with the programatically defined order of multiple emit():

private slots:
  void handleModelChanged() {
    // order explicitly defined
    emit updateComponent1();
    emit updateComponent2();
    emit updateComponent3();

Cheers, Oliver

To unsubscribe - send a mail to [email protected] with 
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/

<Prev in Thread] Current Thread [Next in Thread>