2009-09-05 3 views
2

Mon projet embarqué contient une application Qt pour le PC qui est principalement un simulateur pour le débogage et les tests. Dans l'application, je peux créer plusieurs widgets qui représentent soit mon logiciel embarqué ou simuler le matériel contrôlé par l'application ou peuvent générer des entrées externes pour les tests.Architecture pour application Qt avec script Lua - exécution de pause

Je prévois d'améliorer l'application en ajoutant des scripts Lua afin que les widgets puissent être créés ou contrôlés à partir d'un script. J'ai besoin d'un moyen élégant pour faire un pas sur les scripts. Je prévois des scripts comme:

createThermometerWidget(10,20,30) 
while time < maxTime do 
    setTemperature(20+time/1000) 
    pauseSimulation() 
    time = time + 1 
end 

La fonction personnalisée pauseSimulation doit arrêter le script Lua, activez la boucle d'événement Qt afin de fonctionner de telle sorte que l'interaction avec le logiciel est possible (Seting d'autres entrées, par exemple) et après avoir appuyé sur un bouton le script va continuer.

Ma première idée était de créer un thread séparé pour l'exécution de Lua qui sera arrêté par pauseSimulation et publié par le bouton. Mais les widgets Qt ne peuvent pas être créés à partir d'un thread non principal, de sorte que je devrai créer tous les widgets dans le thread principal et passer tous les paramètres du constructeur des fonctions Lua au thread principal.

Y a-t-il une manière plus douce?

Répondre

3

Coroutines sont une approche pour mettre en œuvre cela. Votre pauseSimulation() peut appeler en interne coroutine.yield() et être redémarré plus tard par un appel à coroutine.resume() à partir de l'action du bouton. Le problème est que votre interface utilisateur est à la merci de vos fragments de script, puisque la seule façon d'arrêter une coroutine en cours est d'appeler le yield().

Vous pouvez également utiliser le module Lanes pour placer une partie de votre application Lua dans un thread séparé. Vous utiliseriez une Linda pour transmettre des messages du thread principal du widget Qt au thread de travail de votre simulateur. Cela aurait l'avantage que le thread UI n'est pas bloqué par la simulation qui s'exécute dans son propre thread.

+0

Merci beaucoup. – danatel

+1

Qt a un support multi-threads décent. Vous pouvez utiliser QThreads plutôt que Lanes pour synchroniser lua avec l'interface graphique de Qt. Le thread de Lua fonctionnerait dans une boucle qui ne reçoit que des messages de l'interface graphique et reprend différentes coroutines. Une bibliothèque externe de moins à s'inquiéter. –

+0

Ma seule préoccupation est que Lua lui-même n'est pas nécessairement thread-safe ou thread-aware. Il est prudent de conserver un état Lua distinct dans chaque thread, mais cet état ne doit être accessible qu'à partir de ce thread. Si la liaison de Qt à Lua rend cela facile, alors c'est une bonne solution. Les voies fournissent un transfert de données synchronisé en toute sécurité entre les threads du système d'exploitation, ce qui permet de répondre à certaines de ces préoccupations. – RBerteig