Well, there isn't a way that I'm aware of to make them deterministic,
you instead just need to make your app either safe to them, or
implement your own way of ordering them correctly, like a class to
absorb and distribute signals the way you want it to. It would be
hard, if not impossible, to make it generic but I've done stuff like
that before and it works (I'm pretty sure it's possible, I wouldn't be
surprised to see the libqxt guys tackle that some time).
Personally I wouldn't mind seeing that become a feature, I know I'd
find it useful. I imagine signals/slots would take a performance hit
though, which wouldn't be cool.
Best of luck!
On Thu, Oct 23, 2008 at 2:51 PM, Elvis Dowson <[email protected]> wrote:
> I was just wondering if there is a way to make the execution of
> slots deterministic.
> Here is an excerpt from the reference doc for Qt 4.4.3: Signals and Slots
> If several slots are connected to one signal, the slots will be executed one
> after the other, in an arbitrary order, when the signal is emitted.
> If Qt is used for the development of a deterministic real-time,
> near-real-time or safety critical application, one must have precise control
> over execution order. One way to achieve this is to enhance the
> implementation so that if several slots are connected to one signal, the
> user should have the ability to specify the priority order for each slot, so
> that they are executed in a sequence, and according to the priority levels.
> This way, when you design a software component, you can test it also in a
> deterministic manner, since at run-time the execution sequence will be known
> before hand.
> The above suggestion is an adaption of the safe-statemachine concept. In
> modeling environments like UML, one can have multiple transitions from a
> single state. However, if all transition events arrive at the same time,
> which transition do you take ? The solution is to prioritize the state
> transitions. In other modeling environments, like simulink, the priority
> ordering is clock-wise order for outgoing state transitions from a state.
> This also is unacceptable, since if you change the model by changing the
> placement of the transitions, the behaviour of the application will also
> change at run-time. Thus, the solution again is to prioritize all out-going
> state transitions.
> Incorporating the feature into Qt, will be an added bonus and help it's
> adoption for some types of GUI intensive safety critical environments.
> Best regards,
> Elvis Dowson
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/