passer thread "en premier plan" lors d'une exception IOError

Version imprimable

Bonjour à tous.

Au sein de mon projet (lié à un Raspberry mais peu importe) j'ai le besoin de vérifier si un des composants est bien connecté pendant que mon programme tourne.
Indirectement ce composant est relié à l'aide d'un câble et pourrait être débrancher par inadvertance.

Pour cette partie seule j'ai fait ce petit bout de code (pas top mais ça marche, au passage si c'est dégueux et qu'il y a plus simple je prends) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #!/usr/bin/python # -*- coding: latin-1 -*- import time import smbus verif = True while verif: #Essayer de faire une lecture du registre sur le bus i2c adresse 0x20 try : val = smbus.SMBus(1).read_byte(0x20) except (IOError): error = True while error : try: val = smbus.SMBus(1).read_byte(0x20) error = False except (IOError): pass time.sleep(0.02) time.sleep(0.02)
Maintenant ce que j'ai besoin de faire :

J'ai mon programme principal qui tourne pour mon IHM, à partir duquel je lance un thread avec le code ci-dessus.
Il faudrait que tant que le "try" provoque une exception IOError, le thread se mette "au premier plan" et empêche le programme principal de fonctionner (que le programme soit en attente de reconnexion du câble en gros). Et le thread repart en tâche de fond tant que c'est connecté et mon programme reprend la main.

Est-ce envisageable de façon pas trop compliquée?

Merci d'avance.

31/08/2018, 17h47
wiztricks

Salut,

Citation:

Envoyé par esope60

Est-ce envisageable de façon pas trop compliquée?

Il faut voir comment est lancé votre "thread" (car ce que vous montrez n'en est pas un)... mais çà risque d'être compliqué.

- W

En effet, alors admettons ce code pour simplifier mon besoin.
Le programme principal tourne en boucle en attendant l'appui sur un bouton.
Si appui, print OK.

Et il faudrait que mon thread surveillant la connexion au semi-conducteur MCP en tâche de fond, empêche de faire tourner le programme principal si j'obtient un IOError.
Je sais arrêter mon thread à partir du programme principal grace à la globale, mais je ne sais pas agir sur le principal à partir du thread et ne vois pas comment c'est possible.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#!/usr/bin/python
# -*- coding: latin-1 -*-
 
import time
import smbus
from threading import Thread
 
import Adafruit_GPIO.MCP230xx as MCP
#définir la variable 'mcp' adressée en 0x20
mcp1 = MCP.MCP23017(address = 0x20, busnum = 1)
#définir l'entrée pour1 interrupteur à l'état haut avec résistance de pull up
mcp1.pullup(0, 1)
 
 
verif = True
def sequence():
    global verif
    while verif:
        try :
            val = smbus.SMBus(1).read_byte(0x20)
        except (IOError):
            error = True
            while error :
                try:
                    val = smbus.SMBus(1).read_byte(0x20)
                    error = False
                except (IOError):
                    pass
                time.sleep(0.02)
 
        time.sleep(0.02)
 
 
if __name__ == "__main__":
    Thread(target=sequence).start()
 
    appui = True
        while appui:
            #jaune
            if mcp1.input(0) == False :
                print("OK")
            time.sleep(0.02)

31/08/2018, 19h59
wiztricks

Salut,

Deux programmes indépendants ne peuvent communiquer qu'en utilisant des mécanismes systèmes (sockets, pipes, fichiers,....) qui permettent l’échanges de messages.
Une mécanique simple pourrait être que le processus qui surveille stocke au démarrage son PID dans un fichier et en cas d'erreur, il se laisse juste mourir. Le processus GUI ira, à intervalles réguliers, lire le fichier, vérifier que le process existe encore et se geler sinon.

Si les programmes ne sont pas indépendants (c'est le processus GUI qui lance celui qui surveille ou bien le thread qui surveille est un thread du processus GUI), on peut envisager d'autres solutions.

- W
31/08/2018, 23h04
esope60

Merci de ton aide.
Je vois ce que tu veux dire.
Que ce soit lire le PID ou lire une valeur dans un fichier si erreur (ça c'est de mon niveau), ok je comprends.

Mais cela m'amène deux questions:
-Quand le process "meurt", il faut bien le relancer quand le câble est rebranché pour surveiller de nouveau, il faudrait gérer ça à quel endroit ?
-Dans mon programme principal, comment je peux lui dire de vérifier à intervalle régulier tout en exécutant le reste des commandes au fil de l'eau ? On en revient à encore un thread et je suis dans le même cas qu'au début ? non ? je m'emballe ? :)

Merci

En gros voici mon programme de base, pas terminé mais on voit bien l'idée (j'en ai parlé avec toi il me semble y a quelques mois tu m'avais aidé pour le lancement aléatoire des différents .py
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 #!/usr/bin/python # -*- coding: latin-1 -*- from subprocess import call import random import pygame #vérifier que le câble entre les deux pupitres sont bien connectés. Sinon jouer un son d'instruction. ##pygame.mixer.init() ## pygame.mixer.music.load("branchement.mp3") ## pygame.mixer.music.play() ## while pygame.mixer.music.get_busy() == True: ## continue jouer = True while jouer : liste_scripts = ["module1", "module2","module3","module5", "module6","module7", "module8","module9", "module11"] #mélanger l'ordre des scripts alea = random.sample(liste_scripts,9) print(alea) #lancer les scripts dans l'odre défini par alea for i in range (0, len(alea)): call("python " + alea[i] + ".py") #puis toujours lancer les modules 4 et 10 en dernier call("python module4.py") call("python module10.py") print("gagné") #Trouver une combinaison d'interrupteurs pour refaire une partie ou arrêter et éteindre le raspberry
Ce programme appelle des .py qui mettent en stand by le programme principal tant qu'ils ne sont pas terminés. Et dans ces .py j'ai des thread pour certains (exemple : le .py attend l'appui sur des boutons jaunes et rouge, et derrière un thread active des leds jaunes et rouge. Lorsque les boutons sont appuyés le thread s'arrête, le .py aussi, et on revient au programme principal pour lancer aléatoirement le prochain .py.
Et le but c'est que peu importe si je me trouve dans mon programme principal ou dans un des .py, la vérification de la connexion doit tout le temps avoir lieu, et figer le programme là où je suis.

Je ne sais pas si c'est assez clair mon explication.
Merci d'avance

01/09/2018, 00h06
esope60

Je viens de trouver quelque chose, dans l'esprit de ce que tu expliquais, est-ce que ça marcherait ?

1) thread de surveillance lancé depuis programme principal
2) au lancement d'un .py écriture dans un fichier de son pid. Si aucun .py encore lancé, ecrire le PID du programme principal (car le câble peut aussi être débranché avant de commencer, il faut le vérifier)
3) lorsque le thread provoque une erreur exécuter ça

>>>import psutil
>>> somepid = "lire_pid_dans_fichier"
>>> p = psutil.Process(somepid)
>>> p.suspend()
Boucler jusqu'à reconnexion, puis:
>>> p.resume()
Relancer la surveillance

L'idée me plaît mais question:
Si depuis le thread je suspends le prog principal (qui a lui même initié le thread) est ce que ça va suspendre le thread associé ou il est indépendant ?
Au pire au lieu d'un thread du coup je peux carrément lancer un .py de surveillance avant le programme principal.
Qu'en penses-tu ?
01/09/2018, 13h53
wiztricks

Citation:

Envoyé par esope60

Ce programme appelle des .py qui mettent en stand by le programme principal tant qu'ils ne sont pas terminés. Et dans ces .py j'ai des thread pour certains (exemple : le .py attend l'appui sur des boutons jaunes et rouge, et derrière un thread active des leds jaunes et rouge. Lorsque les boutons sont appuyés le thread s'arrête, le .py aussi, et on revient au programme principal pour lancer aléatoirement le prochain .py.

Mouais, voilà une construction bien compliquée alors que vous pourriez faire cela plus simplement avec des fonctions. Ce qui permettrait aussi de ne pas avoir à passer par l'environnement système pour communiquer.

Citation:

Envoyé par esope60

Si depuis le thread je suspends le prog principal (qui a lui même initié le thread) est ce que ça va suspendre le thread associé ou il est indépendant ?

J'ai la flemme d'ouvrir la documentation Linux et de tester pour vous...

Ceci dit, il est toujours plus simple d'avoir un "boss" (le programme principal) et des subordonnés qu'on pourra contrôler, relancer,...
Et puisque vous parliez de GUI, il est quand même plus simple de bloquer en affichant une popup qui demande de vérifier la connexion et continuera après l'action sur un Button.

- W
01/09/2018, 16h52
esope60

1 pièce(s) jointe(s)

Je viens de mettre en pratique, pas forcément simple en effet mais ça fonctionne.

Citation:

Mouais, voilà une construction bien compliquée alors que vous pourriez faire cela plus simplement avec des fonctions. Ce qui permettrait aussi de ne pas avoir à passer par l'environnement système pour communiquer.

Je ne maîtrise pas bien les fonctions. Ceci me permet (je trouve) de pouvoir gérer vraiment séparément chaque module (quand je dis module c'est au sens physique, un module = un mini-jeu), sans encombrer mon programme principal. De plus ça m'obligerai à importer un tas de truc soit en début de programme (pas possible car si je décide de ne pas connecter un "module physique" pour maintenance les fonction des modules importés vont générer des erreurs pour matériels non présents), ou dans chaque définition de fonction mais je trouve que ça va faire un gros bazar.
Après c'est vrai qu'avec des fonctions je n'aurais pas eu à me soucier des différents PID, à voir si je reviens sur ma façon de faire. Du coup au lieu d'appeler aléatoirement mes .py j'appellerais aléatoirement les fonction, OK.

Citation:

Et puisque vous parliez de GUI, il est quand même plus simple de bloquer en affichant une popup qui demande de vérifier la connexion et continuera après l'action sur un Button.

ceci sera géré par un son mp3 au niveau d'un HP. Je n'aurais aucun clavier ni écran dans mon IHM finale, pas de GUI:

Voici à quoi ça ressemble :

Pièce jointe 408275

Merci